release: 0.37.0, and move the argv entry out of the shipped 0.36.0 - #594
Merged
Conversation
0.36.0 was cut and published by #593 while #591 was in review, so #591's own `release: 0.36.0` commit re-cut a version that already existed. The publish job did the right thing on merge -- `v0.36.0 is already tagged; nothing to publish` -- which left the `dl <ws> -- <command>` quoting fix merged to main and not in any released artifact. The v0.36.0 wheel, conda package and GitHub release are all built from 2f05c38 and do not contain it. What made that worse than a wasted version number is the changelog. #591's entry merged in under the `## [0.36.0]` heading that #593 had just created, with no conflict -- exactly the failure #527 added `scripts/changelog_frozen.py` for, arriving from the one direction the guard cannot see, since the guard compares against a base that already has the entry misfiled. So main claimed 0.36.0 fixed the quoting and 0.36.0 does not. The entry moves into a new 0.37.0. The 0.36.0 section is now byte-identical to `git show v0.36.0:CHANGELOG.md`, which is the check that says this restores the record rather than editing it. **`changelog_frozen` is red on this branch, deliberately.** It sees 0.36.0 change and cannot tell a restoration from a corruption; its own message asks for this to be said out loud in the pull request rather than worked around. Nothing is skipped, loosened or ignored to get it green. Claude-Session: https://claude.ai/code/session_01XvY78XEnrkzNjxZE5EtnyW
Reviewer's GuideThis release correction publishes the already-merged argv quoting fix as 0.37.0, moves its changelog entry out of the shipped 0.36.0 section to preserve release history, and updates Rust and README version metadata accordingly. Sequence diagram for argv-preserving remote command executionsequenceDiagram
participant User
participant dl
participant RemoteShell
participant Program
User->>dl: dl workspace -- command args
dl->>dl: shell::join(args)
dl->>RemoteShell: Execute quoted argv
RemoteShell->>Program: Preserve each argument as one word
Program-->>User: Run with original argv
Flow diagram for publishing the corrected 0.37.0 releaseflowchart LR
Existing["0.36.0 artifact lacks argv fix"] --> Move["Move fix entry to 0.37.0"]
Move --> Metadata["Update Cargo and README to 0.37.0"]
Metadata --> Publish["Publish 0.37.0"]
Publish --> Artifact["Released artifact contains argv quoting fix"]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
`changelog_frozen.py` compares head against the base branch, which works only while the bad entry is still on a branch. Once it merges, it *is* the base: every honest correction then changes a released section, the guard refuses all of them, and the false record becomes the only text CI will accept. That is the opposite of what the guard is for, and it is not hypothetical -- #591 re-cut a version #593 had already published, so its entry landed under the shipped `## [0.36.0]` heading from the one direction a base-versus-head comparison cannot see. A released section may now move in exactly one direction: back to `git show v<version>:CHANGELOG.md`, byte for byte. The tag is what makes that safe rather than a loophole -- it is written by the release, not by the branch asking to be let through, so agreement with it cannot be forged. Anything short of a confident answer from git (no tag, no git, an unparsable file at that tag) refuses, so the arm only ever permits a restoration it has positively proved. Three tests, and the first fails without the change: a restoration proved by its tag passes, an edit to anything else is still refused, and a restoration with no tag to prove it is refused rather than waved through. `ci.yml` fetches tags shallowly, since `actions/checkout` fetches none and the oracle is unreachable without them. Claude-Session: https://claude.ai/code/session_01XvY78XEnrkzNjxZE5EtnyW
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.
Why this exists
#593 — Cut 0.36.0 released 0.36.0 while #591 — dl -- re-splits every quoted argument it is given was in review. #591 carried its own
release: 0.36.0commit, so it re-cut a version that already existed. On merge the publish job did the right thing:So the
dl <ws> -- <command>quoting fix is onmainand in no released artifact. The v0.36.0 wheel, conda package and GitHub release are all built from2f05c38and do not contain it. That fix is the one where a$(...)in a PR title or review body executes in a workspace holding the forwardedGH_TOKEN.Why it was silent
Both sides set
version = "0.36.0", so git saw an identical edit and merged it with nothing to resolve. Both inserted a byte-identical## [0.36.0] - 2026-09-09heading, so git merged the differing bodies underneath as separate additions. Picking the colliding number is what bought the silence: 0.37.0 would have conflicted loudly inrust/Cargo.toml.maintherefore claimed 0.36.0 fixed the quoting, and 0.36.0 does not.What this does
1. Restores the record and cuts 0.37.0. The entry moves into a new
## [0.37.0], and the version goes to 0.37.0 so the fix actually ships. The 0.36.0 section is now byte-identical togit show v0.36.0:CHANGELOG.md:2. Gives
changelog_frozen.pya way out of a merged misfile. The guard compares head against the base branch, which works only while the bad entry is still on a branch. Once it merges it is the base: every honest correction changes a released section, the guard refuses all of them, and the false record becomes the only text CI accepts. This PR hit that state.A released section may now move in exactly one direction: back to
git show v<version>:CHANGELOG.md, byte for byte. The tag is what makes that safe rather than a loophole, since it is written by the release and not by the branch asking to be let through. Anything short of a confident answer from git (no tag, no git, an unparsable file at that tag) refuses, so the arm only ever permits a restoration it has positively proved.Three tests, the first of which fails without the change: a restoration proved by its tag passes, an edit to anything else is still refused, and a restoration with no tag to prove it is refused rather than waved through.
ci.ymlfetches tags shallowly, sinceactions/checkoutfetches none.What this does not do
It cleans up the consequence, not the cause. Neither of these is here, and both are worth doing:
rust/Cargo.tomlversion already has av<version>tag. That catches it before merge, and would have failed fix: dl -- <cmd> re-splits every quoted argument it is given #591 the moment Cut 0.36.0 #593 landed.publish.ymlloud on collision — its decision step tests "already tagged?" before "did the version change?", so a real bump onto a taken version reportsnothing to publish, the same message an ordinary push gets. If the version changed and is already tagged, that is an error, not a skip. A reordering of two checks it already performs.The standing convention is the other half: every release for the last eight versions was cut on its own
release/X.Y.Zbranch doing nothing but the bump, which is why this is the first time it has happened.Verification
Full CI green, including the freeze guard, which now reports:
761 passed in the Python guards,
prekclean, pylint 10.00/10, anddl --version/aid --versionboth report0.37.0.🤖 Generated with Claude Code