Move the major version tag automatically - #30
Merged
Conversation
The README tells consumers to pin `thoughtbot/importmap-update@v1`, but the `v1` tag was never pushed during the 1.0.0 release because moving it is a manual step in RELEASING.md that is easy to forget. Every release carries the same risk of leaving the documented usage broken. This adds a workflow that derives the major version from the published release tag and force-pushes it, so the floating tag tracks the latest patch without anyone having to remember. The workflow skips prereleases and any tag that is not in vMAJOR.MINOR.PATCH form, so the alpha series cannot move `v1`. It creates a lightweight tag with no release attached, which is what keeps the tag movable now that immutable releases are enabled here. One case is deliberately unguarded: publishing an older patch after a newer one in the same series would move the major tag backwards. Guarding it needs version comparison logic that a single active release line does not justify.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds
.github/workflows/major-version-tag.yml, which force-pushes the floatingmajor version tag (
v1) to the commit of each newly published release.Why
README.md documents
uses: thoughtbot/importmap-update@v1,but no
v1tag existed until today. Moving it is a manual step inRELEASING.mdand it was missed during the 1.0.0 release, so the documented usage pointed at
nothing. Automating it removes the failure mode rather than relying on the
release checklist being followed exactly.
I pushed
v1by hand before opening this, so@v1works today. This keeps itworking for every release after.
Notes for review
if: "!github.event.release.prerelease"keeps the alpha-style prereleases frommoving
v1.env:rather than interpolated into the scriptbody, avoiding expression injection.
vMAJOR.MINOR.PATCHtags trigger a move; anythingelse logs a skip and exits zero.
${TAG%%.*}derives the major from the tag itself, so a futurev1.5.1backport published after
v2.0.0would movev1, notv2.git tag -fwith no-a/-screates a lightweight tag. This matters: therepo has immutable releases enabled, so
v1must stay a bare tag with norelease attached or it would be frozen in place.
RELEASING.mdnow recordsthat constraint.
Deliberately not included:
v1.0). GitHub's docs recommend them, but the ecosystem doesnot follow that. Of ten widely-used actions I checked, seven publish major-only,
and all three that ever published minor tags abandoned the practice years ago
(
actions/github-scriptstopped atv4.1and is on v9;codecov/codecov-actionstopped at
v0.5and is on v7).same series would move
v1backwards. Guarding it needs version comparisonlogic that a single active release line does not justify. Easy to add later.
Testing
The workflow cannot run until the next release is published. Publishing a
throwaway prerelease would exercise the trigger and the skip path, but not the
push path.