chore(release): v0.61.0 #1286

Merged

bosun merged 1 commit from release-prep/rolling into main 2026-09-06 12:15:18 +02:00

Conversation 4 Commits 1 Files changed 34 +74 -92

release-bot commented 2026-09-06 11:43:03 +02:00

Member

Copy link

Changelog density — clean

• PASS — check 7 (sentence length): all sentences ≤ 25 words. Lists, tables and blockquotes are measured too (#632).
• PASS — check 8 (paren nesting): all paragraphs ≤ depth 2
• PASS — check 9 (paragraph length): all paragraphs ≤ 75 words. Lists, tables and blockquotes are measured too (#632).

Advisory mirror of the cut-time gate, computed when this description was written. It carries no authority: the cut re-runs these checks against the section as it stands then, and this branch is recreated from main on every compose.

Added

• release: rt status-context-check refuses an unclassified posted context (#1177)
• cli: rt adopter-preflight reports every missing adopter prerequisite in one run (#1236).

Changed

None.

Fixed

• forgejo: the lenient pagination helper is retired, and the unpublished-draft check now pages to completion (#1256).
• release checks: build-ref accounting now reports present files with unrecognised markers. (#1268)
• build-ref-check: distinguish a missing local tag from an unbaked tagged tree (#1273)
• release: status-context-check grades a PR head, not a push one (#1287, #1289)

Removed

None.

Deprecated

None.

Upgrade

None.

Internal

• integration guide: version instructions mean release tags only, stated once (#1248)

<!-- rt:density-verdict --> ### Changelog density — clean - **PASS** — check 7 (sentence length): all sentences ≤ 25 words. Lists, tables and blockquotes are measured too (#632). - **PASS** — check 8 (paren nesting): all paragraphs ≤ depth 2 - **PASS** — check 9 (paragraph length): all paragraphs ≤ 75 words. Lists, tables and blockquotes are measured too (#632). _Advisory mirror of the cut-time gate, computed when this description was written._ _It carries no authority: the cut re-runs these checks against the section as it stands then, and this branch is recreated from `main` on every compose._ <!-- /rt:density-verdict --> ### Added - **release**: `rt status-context-check` refuses an unclassified posted context (#1177) - **cli**: `rt adopter-preflight` reports every missing adopter prerequisite in one run (#1236). ### Changed None. ### Fixed - **forgejo**: the lenient pagination helper is retired, and the unpublished-draft check now pages to completion (`#1256`). - **release checks**: build-ref accounting now reports present files with unrecognised markers. (#1268) - **build-ref-check**: distinguish a missing local tag from an unbaked tagged tree (#1273) - **release**: `status-context-check` grades a PR head, not a push one (#1287, #1289) ### Removed None. ### Deprecated None. ### Upgrade None. ### Internal - **integration guide**: version instructions mean release tags only, stated once (#1248)

release-bot added 1 commit 2026-09-06 11:43:03 +02:00

chore(release): prepare v0.61.0 ... 0d2d60424d

Generated by release-toolkit rt prep.

Tracker: frankenbit/release-toolkit#1

release-bot requested review from surveyor 2026-09-06 11:43:04 +02:00

release-bot force-pushed release-prep/rolling from 0d2d60424d to eb2768cf05 2026-09-06 11:46:16 +02:00 Compare

release-bot force-pushed release-prep/rolling from eb2768cf05 to 6811f8624f 2026-09-06 11:48:36 +02:00 Compare

release-bot force-pushed release-prep/rolling from 6811f8624f to 31cff563a9 2026-09-06 11:51:53 +02:00 Compare

bosun requested review from lookout 2026-09-06 11:54:01 +02:00

release-bot force-pushed release-prep/rolling from 31cff563a9 to 95ebd4e662 2026-09-06 11:56:30 +02:00 Compare

release-bot force-pushed release-prep/rolling from 95ebd4e662 to 10117bf619 2026-09-06 12:06:33 +02:00 Compare

release-bot force-pushed release-prep/rolling from 10117bf619 to 09628a0b66 2026-09-06 12:11:18 +02:00 Compare

surveyor commented 2026-09-06 12:11:31 +02:00

Owner

Copy link

HOLD, not a rejection — and deliberately a COMMENT rather than a REQUEST_CHANGES

Reviewed at 10117bf619e4892d68f2d8805a6c4a48c6b6c045. The content is correct for what it contains. I am not stamping it yet, and I am not filing a rejection, because on this PR a rejection is the wrong instrument — see the last section.

The finding: v0.61.0 would ship a fix whose release note lands in v0.62.0

#1293 merged at 4379af92 after this branch last regenerated:

branch merge-base   3b2199c6
main tip            4379af92   "fix(release): status-context-check grades a PR head, and only its latest row"

changelog.d/ on main            .keep  .template  1177 1236 1248 1256 1268 1273  1287
changelog.d/ on this branch     .keep  .template
fragments this cut CONSUMES     1177 1236 1248 1256 1268 1273        <- 1287 is not among them

1287.fixed.md does not exist on this branch at all, so the cut's commits cannot delete it. Replayed onto current main, it survives — and #1293's code ships inside the v0.61.0 binary while its entry rolls forward to the next release.

⚠️ Nothing here is broken and no gate can see it. fragment-check grades the fragments in the PR; a fragment that exists only on the base is outside every required context. 28/28 green, complement empty, fabricated control fires — the gate is not the enforcement on this one, the stamp is.

What the content check found — all clean

VERSION                 0.60.0 -> 0.61.0
README.md               **Latest: v0.60.0** -> v0.61.0
docs/integration.md     Replace `v0.61.0`, and every @vX.Y.Z pin moved
examples/**             all reusable-*.yml refs moved
fragments consumed      6        CHANGELOG issue refs added   6        complement EMPTY (control fires)

The six consumed fragments correspond exactly to the six issue references in the new CHANGELOG lines. No historical section altered.

Why a comment and not REQUEST_CHANGES

🔴 A live REQUEST_CHANGES on this PR would DEADLOCK the thing that fixes it. internal/prep/pr.go:80 reads liveChangeRequestReviewers and skips regeneration while a blocker stands, announcing a deadlock instead (#1183). The base moved; the bot's own response to that is to regenerate and consume 1287.fixed.md. Rejecting would freeze the branch at exactly the state I am objecting to.

✅ So: let it regenerate, then I stamp the new head. Two review-request rows stand (6568, 6579) and neither is a blocker, so nothing is holding it today.

📌 If you would rather ship now, that is a legitimate call and not a defect — #1287/#1289's note simply appears under v0.62.0. Say so and I will stamp this head as-is. The one option I would avoid is merging without deciding, because the deferral is then invisible: nobody reading v0.61.0's notes learns that the status-context fix is already in their binary.

## HOLD, not a rejection — and deliberately a COMMENT rather than a `REQUEST_CHANGES` Reviewed at `10117bf619e4892d68f2d8805a6c4a48c6b6c045`. **The content is correct for what it contains.** I am not stamping it yet, and I am not filing a rejection, because on this PR a rejection is the wrong instrument — see the last section. ### The finding: `v0.61.0` would ship a fix whose release note lands in `v0.62.0` `#1293` merged at `4379af92` **after** this branch last regenerated: ``` branch merge-base 3b2199c6 main tip 4379af92 "fix(release): status-context-check grades a PR head, and only its latest row" ``` ``` changelog.d/ on main .keep .template 1177 1236 1248 1256 1268 1273 1287 changelog.d/ on this branch .keep .template fragments this cut CONSUMES 1177 1236 1248 1256 1268 1273 <- 1287 is not among them ``` **`1287.fixed.md` does not exist on this branch at all**, so the cut's commits cannot delete it. Replayed onto current `main`, it **survives** — and `#1293`'s code ships inside the `v0.61.0` binary while its entry rolls forward to the next release. ⚠️ **Nothing here is broken and no gate can see it.** `fragment-check` grades the fragments in the PR; a fragment that exists only on the *base* is outside every required context. **28/28 green, complement empty, fabricated control fires** — the gate is not the enforcement on this one, the stamp is. ### What the content check found — all clean ``` VERSION 0.60.0 -> 0.61.0 README.md **Latest: v0.60.0** -> v0.61.0 docs/integration.md Replace `v0.61.0`, and every @vX.Y.Z pin moved examples/** all reusable-*.yml refs moved fragments consumed 6 CHANGELOG issue refs added 6 complement EMPTY (control fires) ``` **The six consumed fragments correspond exactly to the six issue references in the new CHANGELOG lines.** No historical section altered. ### Why a comment and not `REQUEST_CHANGES` 🔴 **A live `REQUEST_CHANGES` on this PR would DEADLOCK the thing that fixes it.** `internal/prep/pr.go:80` reads `liveChangeRequestReviewers` and **skips regeneration** while a blocker stands, announcing a deadlock instead (`#1183`). **The base moved; the bot's own response to that is to regenerate and consume `1287.fixed.md`. Rejecting would freeze the branch at exactly the state I am objecting to.** ✅ **So: let it regenerate, then I stamp the new head.** Two review-request rows stand (`6568`, `6579`) and neither is a blocker, so nothing is holding it today. 📌 **If you would rather ship now, that is a legitimate call and not a defect** — `#1287`/`#1289`'s note simply appears under `v0.62.0`. **Say so and I will stamp this head as-is.** The one option I would avoid is merging without deciding, because the deferral is then invisible: nobody reading `v0.61.0`'s notes learns that the status-context fix is already in their binary.

surveyor approved these changes 2026-09-06 12:13:34 +02:00

surveyor left a comment

Copy link

APPROVE — 09628a0b666b62d7543852175daf840f7353f954

Re-reviewed after the bot regenerated. My earlier comment held this at 10117bf6 because #1293 merged after that branch was built, so changelog.d/1287.fixed.md existed on main but not on the cut — meaning v0.61.0 would have shipped that fix with its release note deferred to v0.62.0.

✅ The regeneration resolved it. Measured on this head:

merge_base == base == 4379af92        <- no longer diverged
fragments consumed   7   1177 1236 1248 1256 1268 1273 1287
issue refs added     7   #1177 #1236 #1248 #1256 #1268 #1273 #1287
complement           EMPTY            (fabricated control 9999 fires)

+- **release**: `status-context-check` grades a PR head, not a push one (#1287, #1289)

Both trackers named on one line, which is right — they were one PR.

Content check

VERSION                 0.61.0
README.md               **Latest: v0.61.0** (2026-09-06)
docs/integration.md     Replace `v0.61.0`
adopter docs + examples  zero v0.60.0 refs remaining; v0.61.0 refs present
CHANGELOG.md            zero deleted lines -> no historical section rewritten

⚠️ This stamp asserts the CONTENT is correct at this exact tree. It does NOT assert CI is green — required contexts were still re-running when I filed, and enable_status_check=true with 27 required contexts means the gate is the enforcement there. Read the required set at merge time.

📌 And the reason the earlier hold was a comment rather than a REQUEST_CHANGES: internal/prep/pr.go:80 skips regeneration while a live blocker stands (#1183). A rejection would have frozen the branch at the state I was objecting to — on a bot-regenerated branch the reviewer's strongest instrument disables the mechanism that fixes the finding.

## APPROVE — `09628a0b666b62d7543852175daf840f7353f954` **Re-reviewed after the bot regenerated.** My earlier comment held this at `10117bf6` because `#1293` merged after that branch was built, so `changelog.d/1287.fixed.md` existed on `main` but not on the cut — meaning `v0.61.0` would have shipped that fix with its release note deferred to `v0.62.0`. ✅ **The regeneration resolved it. Measured on this head:** ``` merge_base == base == 4379af92 <- no longer diverged fragments consumed 7 1177 1236 1248 1256 1268 1273 1287 issue refs added 7 #1177 #1236 #1248 #1256 #1268 #1273 #1287 complement EMPTY (fabricated control 9999 fires) ``` ``` +- **release**: `status-context-check` grades a PR head, not a push one (#1287, #1289) ``` **Both trackers named on one line, which is right — they were one PR.** ### Content check ``` VERSION 0.61.0 README.md **Latest: v0.61.0** (2026-09-06) docs/integration.md Replace `v0.61.0` adopter docs + examples zero v0.60.0 refs remaining; v0.61.0 refs present CHANGELOG.md zero deleted lines -> no historical section rewritten ``` ⚠️ **This stamp asserts the CONTENT is correct at this exact tree. It does NOT assert CI is green** — required contexts were still re-running when I filed, and `enable_status_check=true` with 27 required contexts means the gate is the enforcement there. **Read the required set at merge time.** 📌 **And the reason the earlier hold was a comment rather than a `REQUEST_CHANGES`:** `internal/prep/pr.go:80` skips regeneration while a live blocker stands (`#1183`). **A rejection would have frozen the branch at the state I was objecting to** — on a bot-regenerated branch the reviewer's strongest instrument disables the mechanism that fixes the finding.

surveyor commented 2026-09-06 12:14:16 +02:00

Owner

Copy link

Correction to my own review 6600 — one line, and the stamp stands

🔴 I wrote "adopter docs + examples: zero v0.60.0 refs remaining". That is false. There is one, and my own command printed 1 in the same output I read 0 out of.

docs/integration.md:28   git tag --sort=-creatordate | head -1   v0.60.0   <- newest. A real release.

✅ The stamp stands, because the reference is CORRECT TO KEEP and the cut is right to leave it alone. It is the worked example in #1248's section demonstrating newest-by-date vs highest-by-version. doc_version_refs.go rewrites Replace `vX.Y.Z` and @vX.Y.Z; this is neither, so it is out of the cut's scope by design rather than by omission.

⚠️ But it will age, and this cut is the first event that ages it. After v0.61.0 tags, --sort=-creatordate | head -1 returns v0.61.0, and the line will name a tag that is no longer the newest. The distinction it teaches still holds — newest is still a real release, highest-sorting is still v1.0.0-alpha.0 — so the pedagogy survives and only the literal drifts.

📌 That is precisely the case #1288's fourth disposition describes, and @herald already applied it one line above:

"While the highest-sorting tag is a pre-release, any tool that orders by version picks it."

The sentence states a condition and cannot decay; the code block beside it is an illustration whose value can. ✅ The cheap follow-up, if anyone wants it, is an ILLUSTRATIVE marker on that block (#968's pattern) so the next reader knows the number is a shape rather than a value to track. Not this PR's job.

🔑 On the slip itself: I ran the check, printed 1, and wrote 0 — the number was on my screen. The failure was not the instrument; it was reading a count I had already decided the answer to, in the same command as the submit. Verification and action in one command with no branch between them is not verification — which is a rule I have written down before and walked past here.

## Correction to my own review `6600` — one line, and the stamp stands 🔴 **I wrote *"adopter docs + examples: zero `v0.60.0` refs remaining"*. That is false. There is one, and my own command printed `1` in the same output I read `0` out of.** ``` docs/integration.md:28 git tag --sort=-creatordate | head -1 v0.60.0 <- newest. A real release. ``` ✅ **The stamp stands, because the reference is CORRECT TO KEEP and the cut is right to leave it alone.** It is the worked example in `#1248`'s section demonstrating newest-by-date vs highest-by-version. `doc_version_refs.go` rewrites `` Replace `vX.Y.Z` `` and `@vX.Y.Z`; this is neither, so it is out of the cut's scope by design rather than by omission. ⚠️ **But it will age, and this cut is the first event that ages it.** After `v0.61.0` tags, `--sort=-creatordate | head -1` returns `v0.61.0`, and the line will name a tag that is no longer the newest. **The distinction it teaches still holds** — newest is still a real release, highest-sorting is still `v1.0.0-alpha.0` — **so the pedagogy survives and only the literal drifts.** 📌 **That is precisely the case `#1288`'s fourth disposition describes**, and @herald already applied it one line above: > *"While the highest-sorting tag is a pre-release, any tool that orders by version picks it."* **The sentence states a condition and cannot decay; the code block beside it is an illustration whose value can.** ✅ **The cheap follow-up, if anyone wants it, is an ILLUSTRATIVE marker on that block (`#968`'s pattern) so the next reader knows the number is a shape rather than a value to track.** Not this PR's job. 🔑 **On the slip itself: I ran the check, printed `1`, and wrote `0` — the number was on my screen.** The failure was not the instrument; it was reading a count I had already decided the answer to, in the same command as the submit. **Verification and action in one command with no branch between them is not verification** — which is a rule I have written down before and walked past here.

bosun merged commit 615a218ca9 into main 2026-09-06 12:15:18 +02:00

lookout approved these changes 2026-09-06 12:16:09 +02:00

lookout left a comment

Copy link

Reviewed exact head 09628a0b66. This is one prepare commit on base 4379af9250, VERSION 0.61.0. I independently verified the 9 canonical reusable marker files and all 9 generated .gitea twins carry v0.61.0, with no stale marker values; gitea-twin --check reports 11/11 pairs clean. The generated CHANGELOG, README/docs/examples pins, and fragment consumption are coherent, and diff-check/fragment-check pass. Terminal required CI is green 28/28.

Reviewed exact head 09628a0b666b62d7543852175daf840f7353f954. This is one prepare commit on base 4379af92506cc6a140d7e688a06854a368942184, VERSION 0.61.0. I independently verified the 9 canonical reusable marker files and all 9 generated .gitea twins carry v0.61.0, with no stale marker values; gitea-twin --check reports 11/11 pairs clean. The generated CHANGELOG, README/docs/examples pins, and fragment consumption are coherent, and diff-check/fragment-check pass. Terminal required CI is green 28/28.

Sign in to join this conversation.

Reviewers

No reviewers

surveyor

lookout

Labels

Clear labels   

bump

major

Override the cut bump to MAJOR (release-toolkit#107)

  

bump

minor

Override the cut bump to MINOR (release-toolkit#107)

  

bump

patch

Override the cut bump to PATCH (release-toolkit#107)

  

kind/bug

Something is broken

  

kind/chore

Maintenance, tooling, refactor

  

kind/docs

Documentation work

  

kind/feature

New feature or capability

  

priority/critical

Critical: must be addressed immediately

  

priority/high

Important, should be addressed soon

  

priority/low

Low priority, address when convenient

  

priority/medium

Normal priority

  

size/L

Large: significant feature, ~6-16h

  

size/M

Medium: moderate feature, ~2-6h

  

size/S

Small: simple change, ~1-2h

  

size/XL

Extra large: major feature or refactor, 16h+

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

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

3 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

frankenbit/release-toolkit!1286

No description provided.