Repository navigation
docs(release): pin by release tag with the recorded manifest commit - #10
Merged
Merged
Conversation
The published release body was a one-line string in the workflow and said only where the source was; the process document left consumers to infer the selector. Consumers need one stable Git reference plus a reviewed record of the exact commit behind it. Release notes are now rendered by `scripts/release.py notes` from the same checked release identity as the manifest, and say that consumers pin the annotated `v<version>` tag and record the commit from the attached manifest in their own reviewed pin record, and that a published tag is never moved. The workflow attaches the rendered body with `--notes-file`, keeping it out of the attested asset set. The process document states the same rule and how to preview the body. A unit test covers the rendered wording. Co-Authored-By: Claude Opus 5 (1M context) <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 published release body was a single inline string in
release.yml("Source release at …"), and the process document did not state which Git
selector a consumer should use. Consumers adopting this library want one stable
reference plus a reviewed record of the exact commit behind it.
scripts/release.pygains anotessubcommand that renders the release bodyfrom the same checked release identity the manifest uses (clean committed
tree, tracked lockfile, validated
Cargo.toml/changelog state). The body saysconsumers pin the annotated tag (
tag = "vX.Y.Z") and record the commit fromthe attached manifest in their own reviewed pin record, and that a published
tag is annotated and never moved.
release.ymlpublishes that rendered body with--notes-file. It is writtenoutside
release-dist/, so the attested asset set andSHA256SUMSareunchanged.
docs/release-process.mdstates the same pinning rule under "Releaseidentities" and documents previewing the body.
scripts/test_release.pycovers the rendered wording.No library source, version or lockfile change; release policy allows this as
release-machinery and documentation maintenance.
Verification
python3 -m unittest discover -s scripts -p 'test_*.py'— 9 tests, OKscripts/check-release-state.sh—release-state: 0.19.1 passedscripts/check-package-release-policy.sh—release-policy: v0.19.1 -> 0.19.1 passedpython3 scripts/release.py notes --output …on the committed tree — renderedthe expected body
git diff --check— cleanCrate lanes (clippy/test/doc) were not run because no Rust source changed.
🤖 Generated with Claude Code