Change development policy to repackaging on every code change

The previous development policy was to only repackage on each release. This prevented contributors from doing casual
beta testing by simply referencing the action as `arduino/arduino-lint-action@main` in a workflow.

Author: per1234

.github/CONTRIBUTING.md

@@ -41,24 +41,27 @@ npm run test
 
 See the [official Github documentation][pat-docs] to learn more about Personal Access Tokens.
 
-### 6. Commit
+### 6. Build
+
+It is necessary to compile the code before it can be used by GitHub Actions. Remember to run these commands before committing any code changes:
+
+```
+npm run build
+npm run pack
+```
+
+### 7. Commit
 
 Everything is now ready to make your contribution to the project, so commit it to the repository and submit a pull request.
 
 Thanks!
 
 ## Release workflow
 
-1. `npm install` to add all the dependencies, included development.
-1. `npm run build` to build the Action under the `./lib` folder.
-1. `npm run test` to see everything works as expected.
-1. `npm run pack` to package for distribution
-1. `git add src dist` to check in the code that matters.
-1. If the release will increment the major version, update the action refs in the examples in README.md
-   (e.g., `uses: arduino/arduino-lint-action@v1` -> `uses: arduino/arduino-lint-action@v2`).
-1. open a PR and request a review.
-1. After PR is merged, create a release, following the `vX.X.X` tag name convention.
-1. After the release, rebase the release branch for that major version (e.g., `v1` branch for the v1.x.x tags) on the
-   tag. If no branch exists for the release's major version, create one.
+Instructions for releasing a new version of the action:
+
+1. If the release will increment the major version, update the action refs in the examples in `README.md` (e.g., `uses: arduino/arduino-lint-action@v1` -> `uses: arduino/arduino-lint-action@v2`).
+1. Create a [GitHub release](https://docs.github.com/en/github/administering-a-repository/managing-releases-in-a-repository#creating-a-release), following the `vX.Y.Z` tag name convention. Make sure to follow [the SemVer specification](https://semver.org/).
+1. Rebase the release branch for that major version (e.g., `v1` branch for the `v1.x.x` tags) on the tag. If no branch exists for the release's major version, create one.
 
 [pat-docs]: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token