ci: keep v1 major tag floating to latest release

[Project516]

Adds a workflow that keeps the floating major version tag (v1) pointing at the latest v1.x.y release.

What it does

• Triggers on pushes of any v* tag.
• For tags matching vX.Y.Z (strict semver), moves the major tag (v1) to that commit and force-pushes it.
• Releases are created manually via the GitHub UI, where the "Publish this Action to the GitHub Marketplace" checkbox is pre-checked (2FA required).

Why

The v1 tag had gone stale — it still pointed at the v1.0.0 commit after v1.0.1 was released — so consumers pinning @v1 were silently on the old version. This prevents that from recurring. Pre-release tags (e.g. v1.0.1-rc.1) do not move the major tag.

Summary by CodeRabbit

• Chores
  • Automated management of release tags for stable, versioned releases.
  • Major version tags now automatically point to the newest compatible stable release.
  • Older releases cannot overwrite a major version tag that already references a newer release.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 9708852e-d9d2-4747-809d-7c23f8dbc314

📥 Commits

Reviewing files that changed from the base of the PR and between f11a0fc and 3c5644c.

📒 Files selected for processing (1)

• .github/workflows/release.yml

---

📝 Walkthrough

Walkthrough

The new GitHub Actions workflow runs on version-tag pushes. It validates stable semantic-version tags, selects the newest release for the major version, and force-updates the major tag only when the triggering release is newest.

Changes

Release tag management

Layer / File(s)	Summary
Configure release workflow .github/workflows/release.yml	The workflow runs on tag pushes, serializes executions, limits job permissions, and checks out full history.
Validate and move major tags .github/workflows/release.yml	The workflow validates vMAJOR.MINOR.PATCH tags, selects the greatest stable release for the major, prevents backward movement, and force-pushes the major tag when appropriate.

Estimated code review effort: 2 (Simple) | ~10 minutes

Sequence Diagram(s)

sequenceDiagram
  participant GitHub
  participant ReleaseWorkflow
  participant GitTags
  GitHub->>ReleaseWorkflow: Trigger on version-tag push
  ReleaseWorkflow->>GitTags: Read stable release tags
  ReleaseWorkflow->>ReleaseWorkflow: Select newest release for the major
  ReleaseWorkflow->>GitTags: Force-push major tag when trigger is newest

Loading

Poem

A rabbit checks each version tag,
Then finds the newest in the stack.
If the release is newest still,
The major tag moves by its will.
Hop, hop—the workflow runs.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: a GitHub Actions workflow that maintains the v1 major tag pointing to the latest stable release.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Project516]

@coderabbitai review

[coderabbitai]

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

Actionable comments posted: 5

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/release.yml:
- Around line 8-9: Set workflow-level permissions to an empty permission set,
then add contents: write only to the move-major-tag job. Keep the job’s existing
behavior unchanged while ensuring no other jobs inherit repository write access.
- Around line 19-23: Update the release workflow around the MAJOR tag update to
fetch remote tags first, identify the greatest stable semantic-version tag
matching the current major, and use that selected tag as the target for git tag
and push operations. Ensure an older triggering TAG cannot move the major tag
backward, while preserving the existing version-pattern validation.
- Around line 3-6: Add a workflow-level concurrency group to the release
workflow triggered by the v* tag push, using a shared key derived from the major
version rather than the full patch tag, so updates to the same major tag are
serialized and do not move backward.
- Around line 19-24: Update the version-matching condition in the release
workflow to reject leading zeroes in all semantic-version components, allowing
only 0 or a nonzero digit followed by digits for major, minor, and patch. Keep
the existing tag extraction and major-tag push behavior unchanged for valid
tags.
- Line 15: Update the actions/checkout workflow step to reference its resolved
full-length commit SHA instead of the mutable v7 tag, while retaining “# v7” as
a readability comment.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: d88a888f-7d51-4102-a867-fcfc8aa01a6e

📥 Commits

Reviewing files that changed from the base of the PR and between 47188de and f11a0fc.

📒 Files selected for processing (1)

• .github/workflows/release.yml