Derive the preview version from a release base, not a prerelease tag - #2
Merged
Merged
Conversation
git describe returns the newest tag, which in this repository is itself a
prerelease: v1.0.0-preview.1. Stripping only the leading v left a base that
already carried a prerelease suffix, and appending the run number produced
1.0.0-preview.1-preview.<run_number>
for every push to main. That string satisfies the SemVer check further down —
the optional group after MAJOR.MINOR.PATCH matches the whole doubled suffix —
so nothing failed; the packages simply published to GitHub Packages under a
name nobody would look for.
Strip any -prerelease or +build suffix along with the v, and assert the result
is MAJOR.MINOR.PATCH before it is used, so a tag the strip cannot reduce (v1.0)
fails here with a readable message rather than inside pack.
This is the same family of bug as c47c871, which fixed the empty-base fallback
in these lines: the base is only trustworthy after it has been checked.
Co-Authored-By: Claude Opus 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.
The bug
git describereturns the newest tag, which in this repository is itself a prerelease —v1.0.0-preview.1. The job stripped only the leadingv, leaving a base that already carried a prerelease suffix, then appended the run number:Every push to
mainpublished under that name. Nothing failed, which is why it went unnoticed: the SemVer guard further down is^[0-9]+\.[0-9]+\.[0-9]+([.-].*)?$, and the optional trailing group happily matches the entire doubled suffix.The fix
Strip any
-prerelease/+buildsuffix along with thev, then assert the result isMAJOR.MINOR.PATCHbefore it is used — so a tag the strip cannot reduce (v1.0) fails here with a readable message rather than deep insidepack.This is the same family as c47c871, which fixed the empty-base fallback in these same lines: the base is only trustworthy once it has been checked.
Verified
Ran the block's logic against each case:
v1.0.0-preview.1refs/heads/main1.0.0-preview.42v1.0.0-preview.1refs/heads/develop1.0.0-dev.42v1.0.0refs/heads/main1.0.0-preview.42refs/heads/main1.0.0-preview.42v1.0.0-preview.1refs/tags/v1.0.0-preview.21.0.0-preview.2v1.0refs/heads/mainDerived base version '1.0' is not MAJOR.MINOR.PATCHKnown limitation, not addressed here
Row three shows it: once
v1.0.0is genuinely released,mainbuilds still compute1.0.0-preview.N, which sorts below the released1.0.0. Previews would then look older than the release they follow. Fixing that means deciding what post-release previews should target — next patch, next minor, or a version read from a file — which is a design call rather than a bug fix. It does not bite today, because the only tag is a prerelease.🤖 Generated with Claude Code