Repository navigation
build: validate every pack against the last release for API breaks - #8
Merged
Merged
Conversation
Owner
Author
|
Dispatched run for this branch (base isn't |
CaffeinatedCoder
force-pushed
the
build/package-validation
branch
from
August 16, 2026 12:07
6a13a83 to
e1053a9
Compare
The README has said "no breaking changes" for two majors running, and the migration sections for 3.0 and 4.0 enumerate the breaks by hand. Nothing checked either: a removed public member packed cleanly, and the claim rested on reading the diff. EnablePackageValidation with PackageValidationBaselineVersion=6.2.0 makes it mechanical. At pack time the SDK restores each package at the baseline from nuget.org and runs ApiCompat over the public surface; a removed or changed member fails the pack with CP0001/CP0002 — in CI's Pack job and in the release gate. For an intentional break, `/p:ApiCompatGenerateSuppressionFile=true` writes CompatibilitySuppressions.xml, each entry one breaking change that belongs in the changelog; the props comment records the workflow. The baseline must move: an API added in 6.3 and removed in 6.4 is invisible to a 6.2 baseline. PackagingConventionTests requires it to be the shipped version or the release directly before it (per CHANGELOG.md), never older — between releases Version is the last release, so the baseline equals it; once Version is bumped the baseline is the release being superseded; two behind fails. Verified: all four packages pack cleanly against 6.2.0 (main has no API change since the release); making RangeSet.Overlaps internal fails the pack with CP0002 naming the member; the convention test passes with the baseline at the shipped version and at the release before it, fails two behind, fails when Version is bumped without moving it, and fails with validation disabled. Co-Authored-By: Claude Fable 5 <[email protected]>
CaffeinatedCoder
force-pushed
the
build/package-validation
branch
from
August 16, 2026 12:10
e1053a9 to
da3ba1b
Compare
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.
Stacked on #7 (both edit
Directory.Build.props); retargets tomainonce that merges.Why
The README has said "no breaking changes" for two majors running, and the migration sections for 3.0 and 4.0 enumerate the breaks by hand. Nothing checked either: a removed public member packed cleanly, and the claim rested on reading the diff. "Prefer a test to a convention."
What
EnablePackageValidation=true+PackageValidationBaselineVersion=6.2.0inDirectory.Build.props. At pack time the SDK restores each package at the baseline from nuget.org and runs ApiCompat over the public surface; a removed or changed member fails the pack (CP0001/CP0002) — in CI's Pack job and in the release gate. Intentional breaks:dotnet pack /p:ApiCompatGenerateSuppressionFile=truewritesCompatibilitySuppressions.xml, one entry per break, which is exactly the list the changelog's migration notes should carry. The workflow is in the props comment.PackagingConventionTests.PackageValidationBaseline_IsTheShippedVersionOrTheReleaseBeforeIt: the baseline has to be the shipped version (between releases, whenVersionis the last release) or the release directly before it (onceVersionis bumped) — never older. That lags by at most one release and forces the move at every bump, so the baseline can't fossilise at 6.2.0.Verified
mainhas no API change since the release).RangeSet<TRange,T>.Overlapsinternal(compiles — internal callers are fine) fails the pack withCP0002: Member '…Overlaps(IRange<T>)' exists on [Baseline] … but not on ….Versionbumped to 6.3.0 passes at 6.2.0 and fails at 6.1.0; fails with validation disabled; conventions suite green.Note: pack now needs network access to fetch the baseline package — CI has it; an offline local pack will fail at the validation step.
EFCore.ComplexIndexes would take the same two properties verbatim; I left it out of this pass since its API surface is far more stable — say the word and I'll mirror it.
🤖 Generated with Claude Code