chore: release stoke 1.5.0 #58
No reviewers
claude-bot-andresmgsl
glm-bot-andresmgsl
kimi-bot-andresmgsl
andres
Labels
No labels
attention
blocked
blocker:ci-red
blocker:conflict
blocker:drill-pending
blocker:unrequested
bug
claimed
documentation
enhancement
epic
merge-next
needs-ruling
needs-triage
offsite
post-merge
ready
release
scope:ci
scope:cli
scope:docs
scope:manifests
scope:packaging
stale
state:addressing
state:bots-reviewing
state:building
state:needs-human
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: heavy-duty/stoke#58
Loading…
Reference in a new issue
No description provided.
Delete branch "build/56-release-1-5-0"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Refs #56
Prepares the 1.5.0 version and release notes from every changelog fragment present at merge base
d6a21c9d9e1a4699d4b07cc76aecaac5ab31e847.Worklog
23,36,43,48,50,54)package.jsonand both package-lock version fields to1.5.01.5.0changelog section and consume every merge-base fragment1.5.0missing-version test sentinel under the ruling on #56Acceptance criteria
Pre-merge
package.jsonand both package-lock version fields are1.5.0, andnpm testpasses1.5.0changelog section, deletion of every merge-base fragment, and only the ruledtest/changelog-section.test.jssentinel move from1.5.0to0.0.0; no behavior changesgit ls-tree --name-only HEAD changelog.d/returns nothingscripts/changelog-section.sh 1.5.0 CHANGELOG.mdprints the complete section, excluding the two ruled fragment-less docs mergesci / testis green on the PR headPost-merge (triage/operator owned)
v1.5.0and records the release runstoke_1.5.0_all.debstoke 1.5.0, and a clean install reportsstoke --versionas1.5.0Verification
npm test— 141 passed.e5ead6a0b3cdb73ef06fb2d93c712f452298cfba:npm test— 141 passed; extractor, version, empty-fragment, excluded-merge, exact-scope, and diff checks pass; Forgejoci / testandlabels / labelsare green at this head.Round log
Round at
e5ead6a0Round passed with no written reply.
chore: release stoke 1.5.0to WIP: chore: release stoke 1.5.0⟲ resuming from
57fc3a3ddf📣 round answered at head
e5ead6a0b3WIP: chore: release stoke 1.5.0to chore: release stoke 1.5.0🔎 reviewing head
e5ead6a0b3package.json, lockversion, lockpackages[""].versionall1.5.0— read all threenpm ci && npm test— 141/141 pass in a detached worktree at this headnpm run check:governance— 4 identities, 5 scope rows validgit ls-tree --name-only HEAD changelog.d/— empty23 36 43 48 50 54; all six consumed verbatim, no extra entries, no hand-written entry for081e05c/01b25cascripts/changelog-section.sh 1.5.0 CHANGELOG.md— exit 0, prints the whole sectiontest/change and is not vacuous: injecting a0.0.0section reds it; reverting it to1.5.0reds it at this headci / testandlabels / labelsgreen at this headRefs #56with no closing keyword bound to#56Verdict submitted.
🔎 reviewing head
e5ead6a0b3d6a21c9confirmed; fragments at base: 23/36/43/48/50/54; changelog.d/ empty at head ✔🔎 reviewing head
e5ead6a0b3Approve at
e5ead6a0b3cdb73ef06fb2d93c712f452298cfba. Reviewed the whole PR in a detached worktree at this head, against #56's pre-merge criteria.Acceptance criteria — all five pre-merge criteria met
Version surfaces. All three read
1.5.0:package.json,package-lock.jsonversion, andpackages[""].version.npm ci && npm test→ 141 tests, 141 pass, 0 fail, so #43's parity guard confirms the three moved together rather than my reading them by eye.npm run check:governance→4 identities resolved; 5 scope rows valid. That is the completeci / testcommand from.forgejo/workflows/ci.yml:25, run locally.Exact diff.
git diff --name-onlyagainst merge based6a21c9is the new1.5.0section, the six fragment deletions, the two manifests, andtest/changelog-section.test.js— nothing else.git diff --name-only <base>..HEAD -- test/returns that one file, and the change inside it is exactly the two ruled lines (L38extract, L42 regex). No behavior change anywhere in the diff.Fragments consumed.
git ls-tree --name-only HEAD changelog.d/returns nothing. I re-read the merge-base set rather than trusting the issue:git ls-tree --name-only d6a21c9 changelog.d/is exactly23 36 43 48 50 54. I diffed each fragment's body against the section programmatically — all six appear verbatim, and the section contains no entry that is not a fragment, so the two deliberately-omitted merges (081e05c#46,01b25ca#33) got no hand-written entry, as the spec requires.The section extracts.
bash scripts/changelog-section.sh 1.5.0 CHANGELOG.mdexits 0 and prints the whole 14-line section. I also ran it the way the door does —VERSION=$(node -p "require('./package.json').version")perpublish-release.sh:42— same result, so the heading form## 1.5.0 — 2026-09-02matches the extractor's$2 == veragainst the version the script actually reads.CI.
ci / testandlabels / labelsboth success at this head (runs 958 and 959), read from the commit status API.The sentinel move is sound and not vacuous
This was the ruled judgement call, so I tested it in both directions instead of reading it:
1.5.0at this head reds the suite —not ok 2 - missing version fails with a reason and no stdout. The coupling the ruling describes is real at this head, not just atd6a21c9.## 0.0.0section intoCHANGELOG.mdreds that same test. The assertion fails when the missing-version path stops holding, so the move relocated the fixture rather than defanging it.0.0.0is absent fromCHANGELOG.md, and the two lines moved together, so thestderrregex cannot pass vacuously against the wrong version.I agree with the ruling's preference for
0.0.0over9.9.9on the stated grounds — a project at1.4.0cannot release0.0.0, so the coupling is removed rather than deferred.Body shape
Refs #56, correctly — the criteria outlive the merge. I scanned the whole body for a closing keyword bound to#56per the #200/#218 finding: the only hit is "Resolve the hard-coded1.5.0missing-version test sentinel under the ruling on #56", whereResolveis separated from#56by a clause and so binds nothing. No auto-close risk.Beyond the criteria, since this tag is the release door's first live proof
Not required pre-merge, but cheap and relevant to the post-merge criteria:
bash scripts/build-deb.shsucceeds and producesstoke_1.5.0_all.deb; its controlVersion:is1.5.0, the packagedpackage.jsoninside reads1.5.0, andnode src/cli.js --versionprints1.5.0. So every version surface the post-merge criteria will check is already consistent — what remains genuinely untestable pre-merge is the token and the network, not the version plumbing.What I could not verify, and what I relied on instead
release.ymlrun, registry servingstoke 1.5.0, clean-container install). Unverifiable before the merge by construction; #56 assigns them to @andres and triage. I take no position on them here.RELEASE_TOKENat the org level.GET /actions/secretsis 403 for me as a restricted user, exactly as triage recorded. Relied on @andres's report in #54 comment 34200. The step ordering inrelease.yml(registry publish before any release call) means a wrong answer still fails with nothing published, so this is not a merge risk.lintianis not installed in this box, sobuild-deb.shskipped its package-lint step (Note: lintian not installed; skipping package lint.). The.debwas built and inspected, but not linted. Not a pre-merge criterion, and CI is unaffected.One non-blocking note for the operator, not a change request on this PR and not this diff's code:
publish-release.shsets the notes only on therelease createpath — if av1.5.0release object somehow already exists, therelease uploadbranch attaches the.debwithout ever applying the notes. For a fresh tag this cannot trigger, so it does not gate the merge; it is worth knowing when reading the run.Nothing blocking. Stop at the merge and let @andres cut
v1.5.0.Approve — release 1.5.0 head
e5ead6a0b3cdb73ef06fb2d93c712f452298cfbameets every pre-merge criterion of #56, verified by running, not reading.What I verified, against #56's pre-merge acceptance criteria:
package.json,package-lock.jsonversion, andpackages[""].versionall read1.5.0; the #43 parity guard passes with them.git diff --name-status d6a21c9..HEADis exactly the new## 1.5.0 — 2026-09-02CHANGELOG section, deletion of all six merge-base fragments (23/36/43/48/50/54, re-read at the merge base myself, matching the issue's measured set), and the ruledtest/changelog-section.test.jssentinel move — nothing else, no behavior changes. Every fragment is folded in verbatim (byte-compared againstgit showof each fragment), grouped Added/Changed/Fixed, placed between# Changelogand## 1.4.0.1.5.0to0.0.0in both theextract('0.0.0')call and the/no section for '0\.0\.0'/assertion — together, and nothing else in that file or any other test file.git ls-tree --name-only HEAD changelog.d/returns nothing.bash scripts/changelog-section.sh 1.5.0 CHANGELOG.mdexits 0 and prints the complete section (body from### Addedonward, per the vendored ceremony extractor's contract proven by the 1.4.0 test); the two ruled fragment-less merges (081e05c!47,01b25ca!44) are absent, as the spec decides.npm test→ 141/141 pass in a detached throwaway worktree at this head (Node v22.12.0). The first run failed 66 tests solely because the fresh worktree had nonode_modules; after a cleannpm ciagainst this PR's untouched lockfile, all pass. No failure case was weakened: the moved missing-version test still asserts exit 1, empty stdout, and the reason.e5ead6ashowsci / test (pull_request)SUCCESS (run 958) andlabels / labelsSUCCESS (run 959); earlier PENDING entries are superseded.Refs #56and no closing keyword precedes#56anywhere in it (the only other mention is "the ruling on #56"), so the issue correctly stays open for its post-merge criteria — this PR is not expected to close it, and triage owns that close.What I could not verify, and what I relied on instead:
v1.5.0by @andres, green tagged run publishing the section as release notes withstoke_1.5.0_all.deb, Debian registry serving 1.5.0) are by design unverifiable pre-merge; I relied on the issue's own scoping (Refs, triage/operator owned) and did not hold the PR for them.RELEASE_TOKEN— same shape as triage's own note: not inspectable from here, and its proof is the tagged run, which is post-merge.Non-blocking note: the CHANGELOG entries carry the fragments' trailing-period-after-parens style (
(#23).); verbatim consumption was the requirement, so this stays as-is.The diff is reviewable as a version-and-notes PR exactly as the issue's criterion demands. The tag push and the release run remain with @andres per the handoff.
Approve — all pre-merge acceptance criteria of #56 verified at head
e5ead6a0b3cdb73ef06fb2d93c712f452298cfba.What I verified, against the issue's criteria in order:
package.json,package-lock.jsonversion, andpackage-lock.jsonpackages[""].versionall read1.5.0(jq at the head). The #43 parity guard enforcing the three-way move is untouched by the diff and runs in CI.git diff --name-status d6a21c9..HEADis exactly: new## 1.5.0section inCHANGELOG.md(+17), deletion of the six fragments present at merge base (23,36,43,48,50,54— re-read at the merge base, not taken from the issue), the three version fields, and the ruled sentinel move intest/changelog-section.test.js(4 lines:extract('1.5.0')→extract('0.0.0')and the regex, both moved together, nothing else in that file). No behavior changes.changelog.d/empty.git ls-tree --name-only HEAD changelog.d/at the head returns nothing.### Added/### Changed/### Fixed, heading## 1.5.0 — 2026-09-02in the extractor-matched form, below# Changelogand above## 1.4.0. The two fragment-less merges (081e05cCONTRIBUTING.md,01b25caREADME) are correctly absent, per the issue's explicit decision.bash scripts/changelog-section.sh 1.5.0 CHANGELOG.mdexits 0 and prints the complete section. The failure case is real, not vacuous:changelog-section.sh 9.9.9exits 1 with empty stdout and the reason on stderr, and0.0.0genuinely does not appear inCHANGELOG.md— so the moved sentinel still exercises the missing-version path (I ran the script directly to confirm the exact assertion the test makes).ci / testgreen on the head. Combined commit status ate5ead6a0issuccess:ci / test(run 958) andlabels / labels(run 959).Body shape:
Refs #56with no closing keyword anywhere near#56— correct for the post-merge criteria, which are triage-owned and not reviewable before the merge.What I could not verify: this box has no
node, so I could not runnpm testlocally (the environment gap the crew report already flags for kimi boxes). I relied onci / testat this exact head — which runsnpm test— being green, plus direct bash-level verification of the one test whose behavior the sentinel change touches. The post-merge criteria (tag, registry, clean install) are out of scope for this review by design.The double period in fragment-derived entries (e.g.
. (#23).) is the fragments' own verbatim text, consumed as the spec requires — not a defect in this PR.🏷️
releaseapplied by triage, after the merge — recording why, since the label is now the only thing on this PR that a machine did not put there.Sweeps 971 and 972 both warned, at 20:16:24Z and 20:16:26Z, while this PR was open at
state:needs-human:Verified before acting, because this warning has a known false-positive shape. !41 drew the identical warning with the arrow reversed (
1.4.0 -> 1.3.0) purely because it was branched before !40's release bump — the detector compares the head manifest against the base head without asking whether the diff touches that file, so any branch cut before a release merge manufactures a phantom. So the check is/pulls/58/files, every time, not the warning text: this PR's file list isCHANGELOG.md+17/-0, sixchangelog.d/*.mddeletions,package-lock.json+2/-2,package.json+1/-1,test/changelog-section.test.js+2/-2. The manifest bump is in the diff —1.4.0→1.5.0, confirmed at the merge commit088e7e2d— so this is a true positive and the label is simply owed.Why after the merge rather than before.
releaseis declared intent: the engine flags its absence and never sets it. It also enumerates open PRs (issueflow-reconcileL1380 and the labels caller alike), so the moment @andres merged at 20:18:58Z nothing in the machinery could ever raise this again — the two warnings above were the last. Left alone, stoke's release history would readreleaseon !40 (1.4.0) and nothing on this one. The two now match.Nothing else on this PR was touched:
scope:docs,scope:packagingandstate:needs-humanare the engine's own and stay as they were at the merge, which is the honest record of where this PR stopped.Recorded on #56 as well, in its Notes, so whoever writes the next release issue applies the label when the PR opens instead of paying this again.