Skip to content

feat: maintain a moving minor tag for action pinning#127

Merged
titouanmathis merged 2 commits into
mainfrom
feat/moving-minor-tag
Jul 16, 2026
Merged

feat: maintain a moving minor tag for action pinning#127
titouanmathis merged 2 commits into
mainfrom
feat/moving-minor-tag

Conversation

@titouanmathis

Copy link
Copy Markdown
Contributor

Why

Consumers want to pin the action to a minor series and get patches automatically, e.g. @0.8.x. GitHub uses: refs don't support wildcards, so @0.8.x is invalid — the established pattern (à la actions/checkout@v4) is a moving tag re-pointed to each release.

What

  • publish.yml: after a stable release, force-move a MAJOR.MINOR tag (e.g. 0.8) to the release commit and push it. Consumers can then pin @0.8 and receive 0.8.x fixes automatically.
  • README: pin examples switched to @0.8 with a "Pinning the ref" note covering moving tag vs exact patch vs SHA vs @main.

Design notes

  • No moving @0 tag. Per the project's 0.x rule, a minor bump marks a breaking change, so the minor series is the compatibility boundary. A moving major tag would cross 0.8 → 0.9 breaking changes and mislead consumers.
  • No trigger loop. The moving tag has a single dot (0.8) and cannot match the *.*.* publish trigger, so pushing it never re-runs the workflow.
  • Prereleases skipped (if: env.IS_PRERELEASE == 'false'), so an rc/beta tag never advances the stable minor pointer.
  • Uses the checkout's persisted GITHUB_TOKEN (job already has contents: write); a lightweight force tag needs no git identity.

The 0.8 tag pointing at 0.8.3 will be created immediately after merge so @0.8 works today; the workflow keeps it current from the next release on.

🤖 Generated with Claude Code

titouanmathis and others added 2 commits July 16, 2026 13:51
Re-point a MAJOR.MINOR git tag (e.g. 0.8) at each patch release so action
consumers can pin `@0.8` and pick up `0.8.x` fixes automatically, mirroring
`actions/checkout@v4`-style moving tags.

In 0.x a minor bump signals a breaking change, so the minor series is the
compatibility boundary — no moving `@0` tag is maintained. The tag has a
single dot and cannot match the `*.*.*` publish trigger, so it never causes a
re-run loop; prereleases are skipped. Documents the pinning options in the
README (GitHub `uses:` refs have no wildcard, so `@0.8.x` is not valid).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown

Code Review

Risk: Low — I did not find blocking defects in this MR; it is safe to merge as-is.

This MR updates the release workflow to force-move a MAJOR.MINOR tag after stable releases and rewrites the README pinning guidance around the new moving-tag pattern. I did not find concrete defects in the implementation shown here. The changelog also records the new action-pinning behavior for the next release.

Notes:

  • The intent says the existing 0.8 tag will be created immediately after merge, but this diff only updates the workflow and docs; it does not include a one-off tag creation step for the current release.

Review usage: 16,465 in (11,264 cached) / 1,240 out tokens — $0.0344 (cloudflare-ai-gateway/gpt-5.4, thinking: medium)

Reviewed by @weareikko/code-review v0.8.3 for commit 007ff5a.

@titouanmathis titouanmathis merged commit 46ed384 into main Jul 16, 2026
6 checks passed
@titouanmathis titouanmathis deleted the feat/moving-minor-tag branch July 16, 2026 11:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant