chore(manifest): record v0.27.0 release retroactively #437
No reviewers
Labels
No labels
bump
major
bump
minor
bump
patch
kind/bug
kind/chore
kind/docs
kind/feature
priority/critical
priority/high
priority/low
priority/medium
size/L
size/M
size/S
size/XL
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/release-toolkit!437
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "i/v0.27.0-manifest-advance"
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?
Summary
v0.27.0 recovery step 3 (manifest advance), per Bosun bus 58c3 hand-off. The v0.27.0 cut workflow was cancelled before it could tag + publish + advance the manifest. Bosun completed steps 1-2 via API (tag + release published at b36955e148caa as release id 199). Bosun's FORGEJO_TOKEN_BOSUN lacks repo-write; hand-off relayed to QM.
Point of no return
Merging this closes the release-decide state loop: on the next
push:main(this merge IS that push), release-decide walks from v0.27.0 and either:mode=noop(no changelog-relevant commits since v0.27.0) → nothing further firesmode=update(there are relevant commits) → v0.28.0 rolling-PR auto-opensThe n=4 substrate deltas merged this sprint (#428 mirror-decouple, #429 orphan-check delegate, #431 prose-quality, #434 register-check bypass gate, #436 line-exemption+header-polish) will compose into v0.28.0's rolling PR. Bug #2 empirical validation happens at that cut.
Substrate
Single-file update to
.release-toolkit-manifest.json:last_released_sha:512aa1a4...→b36955e148caa...last_released_version:0.26.0→0.27.0last_released_tag:v0.26.0→v0.27.0last_released_at:2026-07-05T14:46:34Z→2026-07-06T12:12:12ZSchema unchanged (schema=1).
Verification
releases/tags/v0.27.0returns 200, draft=false, target sha=b36955e148caa)Refs: Bosun dispatch 58c3 (recovery-hand-off), release-toolkit#417 (parent orphan-check arc), operator-authorized recovery per Bosun's upstream ratify.
APPROVED — #437 @
6c4bfed(v0.27.0 manifest advance — recovery step 3)Mechanical, but release-triggering (merge fires release-decide → v0.28.0 rolling PR), so I verified all four field edits against live state rather than eyeballing. Every one checks out.
Verified against live Forgejo state (not the spec, the actual published artifacts)
last_released_sha=b36955e148caad1fa7254394c15f19650e1291dd— thev0.27.0tag points to exactly this commit (git refs API:refs/tags/v0.27.0→ type=commit, lightweight, sha IS the commit). It's an ancestor of main tip3722b35(reachable), subjectdocs(integration): reconcile Cancel-safety…. ✓last_released_version=0.27.0+last_released_tag=v0.27.0— match the published tag. Release exists,draft=false(published). ✓last_released_at=2026-07-06T12:12:12Z— matches the releasepublished_at(14:12:12+02:00=12:12:12Z), to the second. ✓Semantics are correct — this unblocks the recovery cleanly
Before: manifest
0.26.0vs CHANGELOG[v0.27.0]= the #417 orphan signature that blocked the cut. After: manifest0.27.0, CHANGELOG top[Unreleased]→ orphan-check passes. And the next cut's orphan-walk correctly baselines fromb36955e(= the v0.27.0 tag commit), so v0.28.0 walksb36955e..HEADover the accumulated deltas. The baseline SHA being the tag commit is the load-bearing property for the next cut — and it holds.Verified
tag→commit
b36955e(exact) ✓ · sha ancestor-of-main ✓ · version/tag match published release ✓ · date == release published_at to the second ✓ · valid JSON, 4 fields only ✓ · point-of-no-return understood (fires release-decide on merge).Byte-verified against the live tag + release. Ship it — the recovery's last step is sound.