There seems to be a slight misunderstanding in the article. It says that the "v2" tag "looks like an immutable reference" and points out that it's actually mutable, as if this was surprising and unintended. It also says that the reason people use tags despite this (making a tradeoff against security) is that "tags are easier to read and compare".
But the GitHub documentation [0] makes it clear that tags for major versions are intended to be mutable and be updated to point to new minor versions as they are released, not because it's "easier to read" but because you "can expect an action's patch version to include necessary critical fixes and security patches, while still remaining compatible with their existing workflows" (as long as the author follows their recommended semantic versioning scheme).
So choosing a major-version tag is GitHub's recommended practice precisely because it is mutable and does change.
> major versions are intended to be mutable and be updated to point to new minor versions as they are released [...] because you "can expect an action's patch version to include necessary critical fixes and security patches [...]
It's two sides of the same coin: on one hand, an update can include fixes for bugs and vulnerabilities; on the other hand, an update can also include new bugs and vulnerabilities (or even malicious code). Updating too quickly can be risky. Updating too slowly can also be risky.
While this may be technically correct, the general git-community at large mostly treats tags as immutable (contrary to docker, for example).
Release branches are typically the mutable reference. So I would create a 'v2' release branch, but not a 'v2' tag which gets updated.
Also, by convention, git references starting with 'v' are typically immutable tags and not branches.
But, even given the above, the git-community at large knows that tags can be mutable, and so if we care about that, we reference the sha (malicious collisions excepted).
That's a good point and might explain the source of this confusion. Actions on GitHub can come from either Docker or a Git repo, using exactly the same syntax [0], so the tag can be either a Docker tag or a Git tag.
That wording is even more misleading, because it implies that using the full version string, by contrast, is not mutable, even though it presumably is.
But the GitHub documentation [0] makes it clear that tags for major versions are intended to be mutable and be updated to point to new minor versions as they are released, not because it's "easier to read" but because you "can expect an action's patch version to include necessary critical fixes and security patches, while still remaining compatible with their existing workflows" (as long as the author follows their recommended semantic versioning scheme).
So choosing a major-version tag is GitHub's recommended practice precisely because it is mutable and does change.
[0] https://docs.github.com/en/actions/sharing-automations/creat...