Apply versioning and release strategies for an action using tags, release branches and semantic version references.

A maintainer publishes an action and wants consumers who write uses: their-org/setup-tool@v3 to automatically receive every backward-compatible 3.x fix and feature without editing their workflows, while never silently jumping to the breaking 4.0.0 release. After tagging the new commit v3.4.1, which additional step delivers this behaviour following GitHub's recommended versioning practice?

git tag v3.4.1
git push origin v3.4.1
# consumers reference:
# uses: their-org/setup-tool@v3

• ACreate an annotated v3.4 tag on the same commit, because consumers pinning to the minor major.minor tag are the ones GitHub expects to receive backward-compatible patches automatically.
• BOpen a release branch named release/v3 from the commit, because consumers using a bare major reference resolve against the matching long-lived branch rather than against any moving tag.
• CMove the major version tag v3 to point at the v3.4.1 commit, because GitHub recommends maintaining a major tag that always tracks the latest release within that major so @v3 consumers get compatible updates.check_circle Correct
• DMark the v3.4.1 release as latest in the releases interface, because the latest flag is what a bare major reference such as @v3 resolves to whenever a new compatible release is published.

Why A is wrong: Tempting because minor tags do exist, but consumers here reference the major tag v3, so moving only a v3.4 tag would not update what their workflows actually resolve.

Why B is wrong: Tempting since release branches help organise maintenance lines, but a uses reference like @v3 resolves to a Git ref named v3, not to a branch called release/v3, so the branch alone changes nothing for consumers.

Why C is correct: GitHub recommends a moving major tag that you repoint to each newest release in that major line, so consumers referencing @v3 automatically pick up backward-compatible 3.x changes without crossing into 4.0.0.

Why D is wrong: Tempting as the latest label feels authoritative, but the latest flag governs the releases page display, while a @v3 reference resolves to the v3 Git ref and ignores which release is flagged latest.