Skip to content

Move the major version tag automatically - #30

Merged
neilvcarvalho merged 1 commit into
mainfrom
nc/release-workflow-options-b5f955
Aug 28, 2026
Merged

Move the major version tag automatically#30
neilvcarvalho merged 1 commit into
mainfrom
nc/release-workflow-options-b5f955

Conversation

@neilvcarvalho

Copy link
Copy Markdown
Member

What

Adds .github/workflows/major-version-tag.yml, which force-pushes the floating
major version tag (v1) to the commit of each newly published release.

Why

README.md documents uses: thoughtbot/importmap-update@v1,
but no v1 tag existed until today. Moving it is a manual step in RELEASING.md
and 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 v1 by hand before opening this, so @v1 works today. This keeps it
working for every release after.

Notes for review

  • if: "!github.event.release.prerelease" keeps the alpha-style prereleases from
    moving v1.
  • The tag name is passed through env: rather than interpolated into the script
    body, avoiding expression injection.
  • The regex guard means only vMAJOR.MINOR.PATCH tags trigger a move; anything
    else logs a skip and exits zero.
  • ${TAG%%.*} derives the major from the tag itself, so a future v1.5.1
    backport published after v2.0.0 would move v1, not v2.
  • git tag -f with no -a/-s creates a lightweight tag. This matters: the
    repo has immutable releases enabled, so v1 must stay a bare tag with no
    release attached or it would be frozen in place. RELEASING.md now records
    that constraint.

Deliberately not included:

  • Minor tags (v1.0). GitHub's docs recommend them, but the ecosystem does
    not 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-script stopped at v4.1 and is on v9; codecov/codecov-action
    stopped at v0.5 and is on v7).
  • A backwards-move guard. Publishing an older patch after a newer one in the
    same series would move v1 backwards. Guarding it needs version comparison
    logic 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.

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.
@neilvcarvalho
neilvcarvalho merged commit 27bd0ed into main Aug 28, 2026
6 checks passed
@neilvcarvalho
neilvcarvalho deleted the nc/release-workflow-options-b5f955 branch August 28, 2026 18:05
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