Semantic versioning communicates whether a released package, library, image, artifact, or GitHub Action is backward compatible. Its MAJOR.MINOR.PATCH number gives consumers a practical signal about the significance of a change before they adopt it. section 8.5.3
Increment the version component that matches the release change:
- MAJOR for incompatible API changes. section 8.5.3
- MINOR for backward-compatible functionality additions. section 8.5.3
- PATCH for backward-compatible bug fixes. section 8.5.3
For a published action, create a semantic-version tag for every release and pair it with a GitHub release when publishing to the marketplace. Keep a moving tag for the current major version: alongside v3.0.0, publish v3; when v3.0.1 fixes an important bug or security issue, move v3 to that fixed commit. Test the action before release. section 4.2.4 section 4.6
This tag strategy lets action users reference a major line while receiving compatible fixes. It should accompany focused action design, test workflows, documentation, and clear action.yml metadata rather than substitute for them. section 4.6
Semantic versions can be calculated from Git history during CI. GitVersion requires an unshallow checkout, then exposes the final version as GITVERSION_SEMVER and exposes major, minor, and patch details as step outputs. Use the calculated version when publishing a package. section 8.5.3
Listing 8.8 Using the GitVersion action
steps:
- uses: actions/checkout@v3
with: fetch-depth: 0
- name: Install GitVersion
uses: gittools/actions/gitversion/setup@v0.9.7
with:
versionSpec: '5.x'
- name: Determine Version
id: gitversion
uses: gittools/actions/gitversion/execute@v0.9.7
Use GitVersion after checking out complete history so the workflow can derive a semantic version from the commit being built. section 8.5.3
Publishing a patched major line
A v3.0.0 action release includes both v3.0.0 and v3 tags. After a backward-compatible fix, release v3.0.1 and move v3 to it, preserving a current major-version reference for consumers. section 4.2.4 section 4.6
