Repository navigation
docs: add RELEASE-CHECKLIST for verifying the updater - #327
Closed
chaitanyagiri wants to merge 2 commits into
Closed
chaitanyagiri wants to merge 2 commits into
chaitanyagiri wants to merge 2 commits into
Conversation
The auto-updater is only exercised by the NEXT release, and the paths that matter most (timeout to fallback, restart re-entry, the error-state link) are exactly the ones a clean successful release never touches. god asked for this to live in the repo next to the release steps, not in a chat message, because a checklist in a message is a checklist that gets skipped. Captures: the proving-hop logic and the hard release gate (0.4.7 must be a complete signed/notarized pipeline run, not a tag); the happy path a clean 0.4.7 proves on its own; the three fault-injection checks a clean release cannot reach; and the tested-vs-rc-only split as the reporting standard. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014dMe8Mm2eas1SwvUiu3XXr
Contributor
🚫 This PR is missing its before/after evidenceEvery pull request here has to show its work. Screenshots or a short screen recording, before the change and after it.
How to fix it: edit the description, keep the A bug fix with no visible surface still needs it: show the failing behaviour, then the same steps passing. A terminal recording is fine. Genuinely nothing to show — a CI tweak, a typo, a dependency bump? A maintainer can apply the |
…m RELEASE.md Two refinements from review: 1. The founder's plan rehearses the whole hop on prereleases (0.4.6-rc.1 -> 0.4.7-rc.1) BEFORE the real 0.4.6, so the checklist now describes that: same content, executed against the rc, which is the only packaged build that will exist, so it covers the happy path AND both fault-injection tests. Records why it is safe (verified allowPrerelease behaviour, prereleases invisible to stable clients on both paths) and the two version-maths gotchas (start on 0.4.6-rc.1; a machine left on 0.4.7-rc.1 needs a manual reinstall, no auto-downgrade). 2. A checklist a sibling file nobody links to still gets skipped, so RELEASE.md now references it as a required pre-tag step. RELEASE.md is the PUBLISHED release body (body_path in release.yml), so the reference is an HTML comment: seen by the runner editing the notes, invisible to users. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014dMe8Mm2eas1SwvUiu3XXr
chaitanyagiri
added a commit
that referenced
this pull request
Aug 26, 2026
The section matcher ended `(?=\n#{1,6}\s|$)` under the 'm' flag. With 'm', `$`
matches at the end of EVERY line, and the capture group is lazy, so it stopped
at the blank line our own PR template puts after each heading. The captured
section body was therefore always the empty string, hasEvidence('') was always
false, and every PR failed with "Missing evidence: before and after" no matter
what was attached.
Confirmed red on #333, #329, #327 and #326 before this change. The check only
ever passed by accident, when evidence sat on the line immediately after the
heading with no blank line, and even then it saw only that one line.
Replace the multiline `$` with an absolute end-of-input assertion. The tests
read the regex out of the workflow file rather than restating it, so bringing
the multiline anchor back fails here instead of on a contributor's PR. Verified
by mutation: 4 of the 6 fail against the old regex.
This does NOT unblock #333 on its own. Its evidence is a console transcript and
EVIDENCE only matches an image or video, which the last test records so that
changing that policy has to be deliberate.
Collaborator
Author
|
Shipped in v0.4.6 as |
pull Bot
pushed a commit
to codingwatching/munder-difflin
that referenced
this pull request
Aug 27, 2026
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.
What
Adds
RELEASE-CHECKLIST.mdat the repo root: how a release runner verifies the auto-updater actually works.Why in the repo, not a message
The updater's code is only exercised by the next release, and the paths that matter most (timeout to fallback, restart re-entry, the error-state link) are exactly the ones a clean successful release never touches. Per the dispatch: a checklist that lives in a chat message is a checklist that gets skipped, so this lives next to
RELEASE.mdwhere a runner looks.Contents
0.4.6is delivered by0.4.5's updater, so only a hop after0.4.6runs our code. Cut a throwaway0.4.7.0.4.7must be a complete signed/notarized/stapled pipeline run (mac zip + blockmap +latest-mac.ymlpointing at the zip), not a tag.0.4.7proves on its own.Execution is the founder's on
0.4.6since it needs a packaged build. Doc only; no code.