docs: stage v0.21.7 — changelog entry, version bump, status line - #409
Merged
Merged
Conversation
The three things RELEASE_PROCESS §1 requires on main BEFORE a release is cut. None of them was failing, because check-versions compares against the newest TAG and v0.21.6 still is one; they become failures the moment v0.21.7 is tagged. ⛔ THE CHANGELOG ENTRY IS MINE TO OWN. CHANGELOG.md's own maintenance note says to add it "in the same change that publishes the release notes", and #407 shipped the notes without it. This repairs that rather than discovering it at tag time. ⚠ PROVING.md now names a version AHEAD of the newest tag, and that is deliberate and legal. check-versions check 4 says so in its own comment: "AHEAD is legitimate; BEHIND is the bug. Requiring exact equality made the check fail in both directions, so there was no way to stage a release." Verified by running it rather than by reading the prose -- the two documents disagreed (RELEASE_PROCESS says newer passes, the check's heading says must equal), so I bumped the file and ran the gate: exit 0, "names v0.21.7, ahead of the newest tag v0.21.6 (release in preparation)". STATUS.md gets an "in preparation" line above the latest-release line rather than replacing it, because v0.21.6 IS still the latest published release and saying otherwise would be the exact stale-version failure check-versions exists to catch. Not a re-baseline: METHOD_ID 37987b85 is unchanged and was reproduced twice on 2026-09-18 from two different commits (3f6b5c8 and 2419ee2). ⛔ THIS DOES NOT CUT ANYTHING. It stages the docs so a tag is unblocked whenever the release contents have been agreed -- which is a conversation, not a commit.
defenwycke
force-pushed
the
docs/v0217-release-prep
branch
from
September 18, 2026 22:06
7f0f17b to
5a4f96a
Compare
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.
The three things
RELEASE_PROCESS.md§1 requires onmainbefore a release is cut. None was failing —check-versions.shcompares against the newest tag, and v0.21.6 still is one — but all three become failures the moment v0.21.7 is tagged.⛔ The changelog entry is mine to own
CHANGELOG.md's own maintenance note says to add it "in the same change that publishes the release notes", and #407 shipped the notes without it. This repairs that rather than discovering it at tag time.⚠ PROVING.md now names a version ahead of the newest tag — deliberately
The two documents disagreed:
RELEASE_PROCESS.mdsays naming a newer version passes, while check 4's own heading says "must be the newest tag". Rather than pick one, I bumped the file and ran the gate:The script's comment explains why: "AHEAD is legitimate; BEHIND is the bug. Requiring exact equality made the check fail in both directions, so there was no way to stage a release."
STATUS.md gains a line rather than replacing one
v0.21.6 is still the latest published release; overwriting it would be the exact stale-version failure the gate exists to catch. So "in preparation" sits above "Latest".
✅ Not a re-baseline —
METHOD_ID 37987b85unchanged, reproduced twice on 2026-09-18 from3f6b5c8and2419ee2.⛔ This cuts nothing. It stages the docs so a tag is unblocked whenever the release contents have been agreed — which is a conversation, not a commit.