Repository navigation
release: say which Slang binaries a release bundles - #7
Merged
Merged
Conversation
--generate-notes lists merged PRs, so the single fact anyone wants first -- which Slang is inside -- read as one more line among them, if it appeared at all. The notes now lead with it. Both versions are derived at release time rather than written by hand: the bundled binaries from natives/build.gradle.kts, the ABI floor from PINNED_SLANG_VERSION. Neither can drift from what actually shipped, which a hand-maintained changelog line eventually would. The classifier list is read from natives/manifests/, so it stays right if a platform is ever added or dropped. Generated notes still follow underneath. The two versions are equal after a full regeneration and legitimately differ after a natives-only bump, since PINNED_SLANG_VERSION is a floor rather than a lockstep. The wording branches on that: equal says so plainly, divergent explains that the bindings run against newer binaries and why that is safe. Both branches were rendered and checked. Verified by extracting the step and running it against the real repo with `gh` shimmed off PATH, for both the equal and the divergent case. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
Qodana for JVMIt seems all right 👌 No new problems were found according to the checks applied 💡 Qodana analysis was run in the pull request mode: only the changed files were checked View the detailed Qodana reportTo be able to view the detailed Qodana report, you can either:
To get - name: 'Qodana Scan'
uses: JetBrains/qodana-action@v2026.1.3
with:
upload-result: trueContact Qodana teamContact us at qodana-support@jetbrains.com
|
release.yml stated the invariant in a comment -- "The tag must match `version` in
gradle.properties" -- and nothing checked it. The tag named the GitHub Release; the Maven
coordinates came from gradle.properties; the two were never compared.
The failure is asymmetric, which is what makes it worth a guard rather than care. Tagging
ABOVE the version is self-limiting: Central rejects a duplicate version at validation,
before anything is released. Tagging BELOW it -- v0.0.7 while gradle.properties already says
0.0.8 -- publishes 0.0.8 permanently, auto-released, with the tag and the artifact
disagreeing forever and no error raised anywhere. On a pipeline with no review gate and no
way to unpublish, that is worth eight lines.
The check runs immediately after Gradle is set up, before the natives are downloaded, the
tests run, or anything is published, so a mis-numbered tag costs seconds rather than a
permanent artifact. Exercised for all three cases: v0.0.7 passes against version=0.0.7,
v0.0.8 fails, and a tag missing its `v` prefix fails.
CLAUDE.md sent the releaser to the wrong file for the version -- `slang/build.gradle.kts`,
which holds none, as its own line 7 says ("group and version come from gradle.properties").
Until now that doc was the only thing standing between a mis-numbered tag and Maven Central.
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.
--generate-noteslists merged PRs, so the one fact anyone wants first from a release — which Slang is inside — read as one more line among them, if it appeared at all. The notes now lead with it.What a release body looks like now
Rendered by extracting the actual step and running it against the repo with
ghremoved fromPATH:GitHub's generated notes still follow underneath —
--notesprepends rather than replaces.Derived, not written
Both versions are read at release time: the bundled binaries from
natives/build.gradle.kts, the ABI floor fromPINNED_SLANG_VERSION. Neither can drift from what actually shipped, which is the failure mode a hand-maintained line in a changelog eventually hits. The classifier list is read fromnatives/manifests/, so it stays correct if a platform is ever added or dropped, and the step fails loudly rather than publishing blank versions if either read comes back empty.The two versions are allowed to differ
They are equal after a full regeneration and legitimately diverge after a natives-only bump, because
PINNED_SLANG_VERSIONis a floor rather than a lockstep. The wording branches on that rather than papering over it — the divergent case reads:Both branches were rendered and checked, the divergent one by temporarily faking a mismatched floor.
Verification
The step was extracted from the YAML and executed against the real repo for both cases, with a
ghshim onPATHso nothing could reach GitHub. YAML parses.🤖 Generated with Claude Code