Skip to content

github-release: compare with the newest version tag before marking a release Latest - #806

Merged
nesquena merged 1 commit into
masterfrom
claude/release-page-latest
Oct 31, 2026
Merged

nesquena merged 1 commit into
masterfrom
claude/release-page-latest

Conversation

@nesquena

Copy link
Copy Markdown
Owner

A follow-up to #805, from its adversarial review. To decide whether to pass --latest=false, github-release.yml reads the current "Latest" release, and treated any failure of that lookup (a network error, a 5xx, a rate limit) as "no releases yet". In that case GitHub's default applies (make_latest true), so a backfilled older tag or a maintenance release could be marked Latest during an outage. That's reversible, but wrong.

Change

It now compares the tag with the newest vX.Y.Z tag in the repository (gh api --paginate repos/…/git/matching-refs/tags/v, then sort -V). If the lookup fails, the step stops before creating anything (pipefail). It no longer depends on which releases have pages.

Verification

I ran the step's script against a stub gh:

Case Result
Newest tag created with no flag
Older tag (v0.2.0 with v0.3.0 present) --latest=false
v0.9.0 vs v0.10.0 --latest=false, a version sort, not a text sort
v0.10.0 with -rc1 and junk tags present the junk is ignored; no flag
Lookup failing with HTTP 502 stops with exit 1, nothing created

The real run that created https://github.com/nesquena/rabl/releases/tag/v0.18.0 used the previous version. It marked v0.18.0 Latest, correctly, because it is the newest tag.


Generated by Claude Code

… older tag Latest

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DCpeuxhYEgymbSMcsBXyZd
@nesquena
nesquena merged commit 2dda66b into master Oct 31, 2026
8 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.

2 participants