fix: use a publish-safe prerelease bound for version ranges#14
Merged
Conversation
The X.0.0-0 upper bound broke package publish - nuget.org's nuspec
validator rejected the literal string as an invalid Version
('The NuGet package contains an invalid .nuspec file... invalid
Version: 11.0.0-0'), even though it's valid SemVer2. Switching to
X.0.0-preview.0 keeps the same guarantee (numeric dotted identifiers
compare numerically, so preview.0 sorts below preview.1, preview.6.*,
and any real preview build) while being letter-led like our own
lower bounds, which the validator already accepts without complaint.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…or net11.0 net10.0 never resolves to a prerelease in practice - nothing in this repo's dependency graph requests one, and confirmed empirically (isolated restore against [10.0.10, 11.0.0) stayed on 10.0.10 even though 11.0.0-preview.* numerically outranks it). No need for a synthetic bound there. net11.0's floor is itself a preview, which is what flips NuGet's per-package "consider prereleases" switch on for the whole graph - confirmed empirically that this lets a bare next-major bound leak a 12.0.0 preview in once anything else in the graph wants one (NU1107 forced-conflict test). 12.0.0-a keeps the same guarantee as 12.0.0-preview.0 (still letter-led, still sorts below every real preview/rc label) with a shorter, equally arbitrary marker. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Why net10.0 stays on a plain upper bound while net11.0 needs the -a marker isn't obvious from the values alone - it hinges on whether either range's own bounds already reference a prerelease, which flips NuGet's per-package-ID prerelease consideration for the whole graph. Recording the reasoning (and the empirical tests that confirmed it) here so it doesn't need re-deriving next time these get touched. 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.
Summary
The
X.0.0-0upper bound (from #13) broke package publish:-0is valid SemVer2 and sorts below any real prerelease per spec (numericidentifiers always have lower precedence than alphanumeric ones) - but
nuget.org's nuspec validator rejects the literal string anyway. Switching to
X.0.0-preview.0keeps the same guarantee (preview.0sorts belowpreview.1,preview.6.*, and any real preview build via numeric dottedcomparison) while being letter-led, matching the shape of our own lower
bounds, which the validator already accepted without complaint.
Verified locally:
dotnet packonSharpMud.Hostingproduces a nuspec withthe new bound and no validation error.
Test plan
dotnet restore/dotnet packsucceed locally, nuspec inspected🤖 Generated with Claude Code