Release Update Policy for Actions

1. Follow GitHub's guidelines for releasing actions.
2. Follow semver rules for if a release should constitute a patch, minor or major release.
   • Major releases should only be used if a change will break some users' workflows.
   • For example, renaming an input, or adding a new required one.

Releasing

1. Tag the new version with the new tag, depending on the release type (major, minor or patch).
2. Create major and minor alias tags that will be rolled forward, if they do not already exist (also see step 4).

• For example, if creating v1.0.0, also create v1.
• If creating v1.1.0, also create v1 and v1.1.

3. Update the CHANGELOG.md in respective repositories, for all release types.
4. Roll forward any existing tags that should "include" this version.

• If the release is a patch release, roll forward the major and minor tags.
• Else if the release is a minor release, roll forward the major tag.
• Else if the release is a major release, there is no roll forward and users must upgrade by hand.

Tagging example

If the current release is v2.1.1 and you are releasing v2.1.2: 0. v2 and v2.1 should already exist.

1. Tag v2.1.2
2. Update the v2.1 minor tag to point to the same commit as v2.1.2
   • git tag -d v2.1 && git tag v2.1
   • This is rolling forward the minor release
3. Update the v2 major tag to point to the same commit.
   • git tag -d v2 && git tag v2
   • This is rolling forward the major release
4. Delete the tags you are overwriting from the remote.
   • git push upstream --delete v2.1 --delete v2
5. Push all 3 tags

Note the previous patch release v2.1.1 is not changed.

• Users pointing to action@v2 will get all minor and patch changes.
• Users pointing to action@v2.1 will only get patch changes.
• Users pointing to action@v2.1.1 do not get any changes.

Publishing to the marketplace

Patch versions are not published to the marketplace. The minor tag is rolled forward to include the patch change, so users coming from the marketplace will still get the patch change. Patch changes are not published directly to keep the page a little cleaner.

Minor and major versions are published to the marketplace. We want the major rolling tag to show up as the "newest" release at all times. We want users to pick up the major tag so they get all the minor-level fixes and improvements.

When a tag is rolled forward via force-push or delete/recreate, the release goes into "draft" mode. The release must be re-saved to keep the Action published.

So, the process is:

1. Update all tags as described above
2. Edit the minor rolling release (if it is a patch-level change) so that it picks up the new tag, and save it.
3. Edit the major rolling release (if it is a patch-level or minor-level change) so that it picks up the new tag, and save it.

This way, the major release will be newer than the minor one since it was edited "more recently".

Updating Release notes of the major version

If you release any minor version, update the release notes with all the feature that are included in the minor released version.