ci: Make the public API gate block the merge - #53
Merged
Merged
Conversation
The job has been warning since it was added, because it compares against the newest tag and that tag was v0.5.0, which v1 deliberately broke from. A blocking gate would have failed the release PR that created the thing it compares against. v1.0.0 exists now and the script reports both public packages compatible with it, so the step reduces to the script alone. From here an incompatible change does not fail a check to be argued with; it needs a /v2 module path and an edit in every caller. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GuMYXaDafWUk2fAjyEvFDa
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.
Problem
The API-compatibility job has only ever warned. It compares the branch against the newest
release tag, and until an hour ago that tag was v0.5.0, which v1 deliberately broke from.
Turning it into a gate any earlier would have failed the very PR that created the release
it compares against.
Solution
v1.0.0 exists, so the step reduces to the script alone. I checked before changing
anything:
scripts/api-compat.shon this branch reports both public packages compatiblewith v1.0.0 and exits zero, so the gate passes on a clean tree rather than needing an
exemption on day one.
What changes in practice is not the check but the remedy. Before, an incompatible change
produced a warning somebody could read and merge anyway. Now it produces a red check, and
the way past it is a
/v2module path and a new import line in every caller, which is adesign decision rather than a version bump. Adding to the API is still free.
docs/guidelines.mdsays this outright, including the one thing the tool cannot catch: atype aliased out of an internal package is invisible to it, which is why the public types
are declared in their own package.
Other Changes
None. No Go files touched.
No screenshots: nothing rendered changed.
Related: #50, #52
🤖 Generated with Claude Code
https://claude.ai/code/session_01GuMYXaDafWUk2fAjyEvFDa