v0.15.2 post-publication: record digests, flip state, sweep pointers - #361
Merged
Conversation
v0.15.2 is published. PyPI reports it as the latest version and the GitHub Release is stable rather than a draft. Artifact digests recorded in docs/release/v0.15.2-checksums.txt. They were verified from two independent sources rather than copied from one: the PyPI JSON API advertises them, and downloading the GitHub Release assets and hashing them locally produces the same values. The published SHA256SUMS asset agrees as a third reading. b68d9dd8...6aea2b16 alice_memory-0.15.2-py3-none-any.whl 644af582...e9c91ed7 alice_memory-0.15.2.tar.gz Release-note state moves from pending/pending to published/recorded, now that the artifacts exist and their digests are on disk. Control docs move from naming v0.15.2 as a candidate to naming it as the published baseline, and the two pointers that name the latest published tag for immutable installs follow. One procedural note for the next release. The gate has to run twice and the two runs prove different things. Dispatched from the branch it proves the tree is sound before a tag exists, which is the rule that came out of burning v0.15.0. Dispatched from the tag it registers the exact-SHA check that the publish workflow requires on the release commit itself. Running only the first leaves the publish gate failing closed with "missing required exact-SHA check", which is what happened here and cost one round trip. Nothing was published by that attempt and no recovery path was needed.
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
It was swept into the previous commit by a broad path add. The roadmap is a planning document and belongs in its own change, not in the commit that records published artifact digests, where it would sit in the release history for anyone auditing what v0.15.2 shipped. The file is unchanged on disk and stays untracked until it lands deliberately.
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.
v0.15.2is published. PyPI reports it as latest and the GitHub Release is stable, not a draft.Digests, verified from two independent sources
The PyPI JSON API advertises these, and downloading the GitHub Release assets and hashing them locally produces the same values. The published
SHA256SUMSasset agrees as a third reading. Recorded indocs/release/v0.15.2-checksums.txt.State changes
Release-note state moves
pending/pendingtopublished/recorded. Control docs stop callingv0.15.2a candidate and start calling it the published baseline. The two docs naming the latest published tag for immutable installs follow.Procedural note for the next release
The release gate has to run twice, and the two runs prove different things. From the branch it proves the tree is sound before a tag exists and becomes immutable, which is the rule that came out of burning
v0.15.0. From the tag it registers the exact-SHA check the publish workflow requires on the release commit. Running only the first leaves publish failing closed withmissing required exact-SHA check. That happened here and cost one round trip; nothing was published and no recovery path was needed.