Conversation
GitHub's Immutable Releases feature locks a release's assets and tag permanently the instant it's published, with no override. The old design triggered on a tag push, but the only way to create a tag through the Release UI/API is to publish first - so "publish, then upload" was the only sequence physically possible, and Immutable Releases forbids exactly that sequence. v26.9.1 hit this: the release got published (creating the tag) before this workflow's build finished, so the upload step failed with "Cannot upload assets to an immutable release" and shipped with zero attached binaries. Retargets the trigger to push on main and adds a detect-version job that diffs CMakeLists.txt's CalVer against existing tags, so ordinary pushes to main (CI-only fixes, etc.) are a no-op and only an actual version bump builds+releases. The sign-and-upload job now owns the entire sequence itself - attach assets to the still-draft release, then explicitly publish as its last action - removing every manual "push a tag" / "publish the draft" step a human (or Claude) could get wrong. It also refuses to proceed (loud CI failure, not a silent partial release) if it ever finds the release already published before it gets to upload. This only prevents recurrence for the next release; v26.9.1 itself still needs manual recovery since its release object is already immutable. Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
v26.9.1's tag is permanently unusable — it was published (creating the tag) before its build finished, which under GitHub's Immutable Releases feature locked it with zero assets attached, and deleting the release does not free the tag name for reuse. 26.9.2 is the real first artifact-bearing release of September 2026, cut through the release.yml fix in #27 rather than any manual tag/publish step. Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
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
1 participant
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.
Supersedes the abandoned
v26.9.1(never shipped — see ROADMAP.md). Same feature content as that attempt, plus the fix for why it failed.Highlights
release.ymlnow triggers on the version bump landing onmain, not on a tag push, and publishes only after assets are confirmed attached. The old design's only possible sequence ("publish, then upload") was exactly what GitHub's Immutable Releases feature forbids, which is what sankv26.9.1.What happens after this merges
Nothing manual. The fixed
release.ymlwill detect that26.9.2has no existing tag, build the Windows/Linux artifacts, sign them, attach them to a draft release, and publish — automatically, on this push tomain. No tag push, no "publish the draft" click, from anyone.🤖 Generated with Claude Code