v0.15.3 release prep: first release from AliceMemory - #366
Merged
Conversation
Version moves to 0.15.3 in both manifests, with release notes, changelog entry and candidate markers across the control docs. This is a maintenance release with no functional change to the library, and the notes say so plainly rather than dressing it up. Its reason to exist is that project URLs are frozen into the wheel at build time and the PyPI page renders the latest release, so the corrected repository name only becomes visible to anyone once a version ships from it. It also exists to exercise the post-rename publish path while the change is fresh. PyPI keys its trusted-publisher lookup on repository name and does not check repository id, so a rename breaks publishing until the PyPI side is updated, and GitHub's redirect never reaches an OIDC claim. The new publisher is in place and scoped to the pypi environment, which both id-token jobs declare. Finding a problem with that on a docs release is much cheaper than finding it during a security hotfix, which is also why the publish action bump is held. Contents are the CodeQL atomic pin move, setuptools 84 with the twine range widened, the pnpm action pin converted to a commit SHA, a testing-library patch, and four corrections to systemd unit names that were never shipped. The notes repeat the v0.15.2 limitations rather than assuming anyone reads two sets of notes. None of them are closed: /v1 authenticates without authorizing, /v1 writes are unattributed, the uvx path stores nothing retrievable, importers trust the selected directory, and archived evidence is normalized text. Release-note state is pending/pending until the artifacts exist. Verified: release_check PASS for 0.15.3, control-doc truth PASS, release-static clean including the step that made v0.15.0 untaggable, make release-artifacts green end to end with both artifact smokes passing, 4544 unit passed 2 skipped, ruff and mypy clean across 233 files.
![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.
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.
Cuts
v0.15.3. Maintenance release, no functional change to the library, and the notes say so rather than dressing it up.Why it exists
Two reasons, both about the rename.
Project URLs are frozen into the wheel at build time, and the PyPI page renders the latest release. The corrected repository name is invisible to anyone until a version ships from it.
It rehearses the post-rename publish path while the change is fresh. PyPI keys its trusted-publisher lookup on repository name and explicitly does not check repository id, so a rename breaks publishing until the PyPI side is updated, and GitHub's redirect never reaches an OIDC claim. The new publisher is in place, scoped to the
pypienvironment, which bothid-token: writejobs declare (publishat publish-pypi.yml:245,resume-pypiat :385). Finding a problem here is far cheaper than finding it mid-hotfix, which is also why the publish action bump (#349) stays held.Contents
<8.0, pnpm action pin as a commit SHA@testing-library/react16.3.2Verification
release_checkPASS foralice-memory 0.15.3release-staticclean, including the step that madev0.15.0untaggablemake release-artifactsgreen end to end, both artifact smokes passingOrdering
No tag exists yet. The gate gets dispatched from this branch and seen green before anything is tagged, then again from the tag, which is what v0.15.2 taught us: the tag run is what registers the exact-SHA check the publish workflow requires.