Don't bump the version after a release candidate - #396
Merged
Conversation
The bump_version job ran on rc tags and proposed a version that went backwards: after 3.0.0rc1 it opened a PR setting Version.swift to 2.5.2-pre.53adfaf, regressing main from 3.0.0-pre. Cause: rc tags use the form X.Y.ZrcN, which is not valid semver — that would be X.Y.Z-rcN. reecetech/version-increment cannot parse it, so it fell back to the last parseable tag (2.5.1) and incremented that. Bumping after a release candidate is wrong regardless of parsing, so the job now skips prereleases outright rather than papering over the tag format. Reusing the build job's prerelease output keeps one source of truth for what counts as a prerelease. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe release workflow now runs ChangesRelease workflow
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
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.
Found by cutting
3.0.0rc1. The release itself worked end to end — notarized, published, correctly marked as a prerelease, and Homebrew correctly left alone — butbump_versionthen opened #395 proposing to setVersion.swiftto2.5.2-pre.53adfaf.That is backwards:
mainis at3.0.0-pre, and merging it would have regressed the version to a 2.5.x string.Cause
The rc tag format is
X.Y.ZrcN. That is not valid semver — semver requiresX.Y.Z-rcN, with a hyphen.reecetech/version-incrementcould not parse3.0.0rc1, silently fell back to the last tag it could parse (2.5.1), and incremented that to2.5.2.Worth noting this is the same root cause as the
prereleasebug fixed in #394: the old check wascontains(github.ref, '-'), which assumed the semver hyphen that this tag format doesn't have. The non-standard tag format has now caused two separate defects.Fix
Skip
bump_versionfor prereleases entirely. Bumping the version after a release candidate is wrong on its own terms — the rc is not the release — so this is the correct behaviour regardless of the parsing problem, and it doesn't paper over the tag format.The condition reuses the
buildjob's existingprereleaseoutput rather than re-deriving it, so there is one source of truth for what counts as a prerelease.Not fixed here
The tag format itself. Migrating
X.Y.ZrcN→X.Y.Z-rcNwould make it real semver and remove this whole class of bug, but it changes an established convention and affects the tag-matching patterns. Worth doing deliberately, separately.🤖 Generated with Claude Code
Summary by CodeRabbit