feat: drop floating tags in favor of immutable releases

[TerryHowe]

Summary

• Removes .github/workflows/update-version.yml, which force-pushed the floating v1 and v1.2 tags on every release. These mutable tags are incompatible with GitHub's Immutable Releases ruleset feature.
• Updates README examples to pin to the full patch version (@v2.0.0) rather than the floating major tag (@v1), following the GitHub security hardening guide.

Motivation

Floating mutable tags (v1, v1.2) are a supply chain risk: a compromised token could silently redirect every user pinned to @v1 to malicious code — exactly the class of attack seen in the Trivy supply chain compromise. Removing force-pushes and enabling immutable releases eliminates this vector.

Follow-up required (repo settings)

After merging, enable the Immutable Releases ruleset in repository Settings → Rules → Rulesets:

• Target: all tags
• Rules: Restrict deletions + Restrict force pushes

This cannot be done via code, but is the step that makes releases fully immutable.

Breaking change

Users pinning uses: oras-project/setup-oras@v1 or @v2 will no longer receive automatic updates once those floating tags stop being updated. They should migrate to a full version pin (e.g., @v2.0.0) or a commit SHA.

Partial #163

🤖 Generated with Claude Code

[v-jessehouwing]

The floating tags are not incompatible with immutable releases. But you should only push a tag for v1 and v1.1, not create a release.

This allows people who want mutability to stay on "v1.*" and for people who need immutability to pin to "v1.1.1".

The docs are terrible in this regard, but I've done quite a bit of research into the topic and worked directly with the PM from GitHub on the topic... And built this action which checks whether all the settings were set correctly.

https://github.com/jessehouwing/actions-semver-checker

Immutable releases aren't setup through Rulesets either, but through repository settings directly. Existing releases aren't automatically made immutable.

You can add a ruleset to restrict who can force push tags, to set strict limits on who can change the floating versions.

Ideally the floating tags will go away completely at some point.

Also remember that even if you stop using floating tags directly, people can still push a branch with the name of a release, which will take presendence over the actual tag/release (don't ask me why). So you'll want a ruleset for that as well.

I blogged about the rulesets to configur:
https://jessehouwing.net/protect-the-repository-hosting-your-github-action/