Skip to content

Fix major version tag not being updated on release - #31

Merged
ocean90 merged 1 commit into
masterfrom
ci/fix-major-version-tag
Jul 21, 2026
Merged

ocean90 merged 1 commit into
masterfrom
ci/fix-major-version-tag

Conversation

@ocean90

@ocean90 ocean90 commented Jul 21, 2026

Copy link
Copy Markdown
Member

Problem

The v1 tag still points to the v1.2.0-era commit and was never moved to v1.3.0. The current workflow uses Actions-R-Us/actions-tagger@v2 without a permissions: block, so with GitHub's read-only default GITHUB_TOKEN it cannot push the updated major tag.

Change

Replace it with the same script-based workflow used in wearerequired/lint-action, which:

  • declares permissions: contents: write explicitly, and
  • force-updates the vMAJOR tag (e.g. v1) to the released commit via git tag --force / git push --force.

[[ … ]] is fine here since workflow run: steps default to bash.

Note

This only takes effect on the next release. After merging, publishing v1.3.1 should move v1 automatically. The current v1 can also be repointed manually once v1.3.1 is tagged:

git tag --force v1 v1.3.1 && git push --force origin v1

The previous versioning workflow used Actions-R-Us/actions-tagger without an
explicit permissions block. With GitHub's read-only default GITHUB_TOKEN it
cannot push the major tag, so `v1` was never moved to v1.3.0.

Replace it with the same script-based workflow used in wearerequired/lint-action:
it declares `contents: write` and force-updates the `vMAJOR` tag to the released
commit via git.
@ocean90
ocean90 merged commit 6bbc55f into master Jul 21, 2026
2 checks passed
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