Cut an exact version release first, such as v1.4.2, then update the v1 major tag to the same commit from a protected workflow. GitHub's guide notes that immutable releases prevent force pushing tags tied to releases, so choose between them deliberately.
Why Actions use moving tags
Users of an action usually write a reference like the v1 major tag, so they receive fixes without editing workflows. That works only because the maintainer moves the v1 tag forward with each release. GitHub's guide on releasing and maintaining actions describes configuring a workflow that runs when a release is published or edited, and that ensures semantic tags are in place, using an action that force pushes the major, minor and patch tags.
The trade off is plain: a moving tag is a mutable name. Anyone who can move it controls what every user of v1 runs next.
Steps for a safer release
- Test on every change. Run unit and integration tests on pushes and pull requests.
- Publish an exact version. Create a release for v1.4.2 from the tested commit. Write release notes people can read.
- Move the major tag from automation. Let a workflow with narrow permissions do it, not a person's laptop.
- Limit who can push tags. Use repository rules so only that workflow and a few maintainers can create or move release tags. See protect release tags with a ruleset.
- Log what moved. The workflow run is your record of who moved v1 and to which commit.
The immutable releases note
GitHub's page states that if you enable immutable releases for a repository, you cannot use the force pushing action to move tags tied to releases. It points to separate documentation on using immutable releases and tags to manage your action's releases. Read that page before choosing, because it changes the workflow. The aim is the same either way: users should be able to tell what code a reference resolves to.
What users should do
Publishers carry part of the risk, but consumers choose their own exposure.
| Reference style | Updates automatically | Risk if the tag is moved maliciously |
|---|---|---|
| Major tag | Yes | Highest |
| Exact version tag | No | Lower, still a tag |
| Full commit SHA | No | Lowest for that reference |
Many teams pin to a commit SHA and let an update tool propose changes. See pin GitHub Actions to a SHA or a tag.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through a blocked pull request and note how a gate checks a change before it can merge, which is where your action's own changes should be reviewed.
Quick check
Is a moving major tag a bad practice?
It is a convenience with a cost. If you offer one, restrict who can move it and also offer exact versions for users who want stability.
Which reference is safest for users?
Pinning to a full commit SHA, since a commit hash cannot be repointed, with an update tool to bring in new versions.
Sources
Last reviewed: 19 October 2026.
