chore(release): v0.59.0 #1213

Merged

bosun merged 1 commit from release-prep/rolling into main 2026-09-06 00:11:48 +02:00

Conversation 4 Commits 1 Files changed 32 +69 -71

release-bot commented 2026-09-05 22:51:34 +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

• dispatch-check: diagnose whether a commit was reported and dispatched (#1110).

Changed

None.

Fixed

• release: a tag with no .goreleaser.yaml is now named as such, not reported as a config that parses (#1194).
• docs: document the lockstep artifact set contributors check when adding a CLI verb (#1196).
• release: a rebuild derives the asset set from the tag's own config, not from today's (#1197).
• gates: base-divergence-check no longer reports "behind base" from the cached merge_base alone (#1202).
• release cut: rt bake-digest refuses the all-zeros placeholder instead of baking it into a published action (#1205).
• docs: the integration guide names v0.57.0 as the earliest tag a gitea.com adopter can pin (#1206)

Removed

None.

Deprecated

None.

Upgrade

None.

<!-- 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 - **dispatch-check**: diagnose whether a commit was reported and dispatched (#1110). ### Changed None. ### Fixed - **release**: a tag with no `.goreleaser.yaml` is now named as such, not reported as a config that parses (`#1194`). - **docs**: document the lockstep artifact set contributors check when adding a CLI verb (#1196). - **release**: a rebuild derives the asset set from the tag's own config, not from today's (`#1197`). - **gates**: `base-divergence-check` no longer reports "behind base" from the cached `merge_base` alone (`#1202`). - **release cut**: `rt bake-digest` refuses the all-zeros placeholder instead of baking it into a published action (#1205). - **docs**: the integration guide names `v0.57.0` as the earliest tag a gitea.com adopter can pin (#1206) ### Removed None. ### Deprecated None. ### Upgrade None.

release-bot added 1 commit 2026-09-05 22:51:34 +02:00

chore(release): prepare v0.58.1 ... 6e95e70aee

Generated by release-toolkit rt prep.

Tracker: frankenbit/release-toolkit#1

release-bot requested review from surveyor 2026-09-05 22:51:35 +02:00

surveyor approved these changes 2026-09-05 23:09:17 +02:00

Dismissed

surveyor left a comment

Copy link

APPROVED at 6e95e70a.

The bake is complete — that is the claim worth checking on a cut, and it is the one #1209 exists because of.

16 workflow files under .forgejo/ and .gitea/
16 BUILD_BAKED_TOOLKIT_REF: 'v0.58.1'
 0 left as 'main'

Positive control: the same sweep run against origin/main returns 'main', so it can see the placeholder it is claiming the absence of.

Rest of the cut is mechanical and consistent: VERSION 0.58.0 → 0.58.1, the #1194 fragment consumed into a ### Fixed entry and deleted, README and the four examples/ workflows repinned, docs/integration.md repinned at 12 sites. The None. sections are correct for a one-fragment patch cut.

Required set: 0 not-green of 26, with enable_status_check=true — so the green is enforcement here, not a list.

Scope

Not graded: whether v0.58.1 is the right bump for #1194. That is a fix:-only cut, so patch is consistent, but the bump decision is rt prep's and I did not re-derive it.

📌 This is the first rolling cut to arrive with a reviewer already requested — RELEASE_PR_REVIEWERS at 21:50. Three previous cuts had zero rows and waited on someone noticing. The row is what made this one reviewable on sight.

APPROVED at `6e95e70a`. **The bake is complete — that is the claim worth checking on a cut, and it is the one `#1209` exists because of.** ``` 16 workflow files under .forgejo/ and .gitea/ 16 BUILD_BAKED_TOOLKIT_REF: 'v0.58.1' 0 left as 'main' ``` Positive control: the same sweep run against `origin/main` returns `'main'`, so it can see the placeholder it is claiming the absence of. Rest of the cut is mechanical and consistent: `VERSION` 0.58.0 → 0.58.1, the `#1194` fragment consumed into a `### Fixed` entry and deleted, README and the four `examples/` workflows repinned, `docs/integration.md` repinned at 12 sites. The `None.` sections are correct for a one-fragment patch cut. **Required set: 0 not-green of 26**, with `enable_status_check=true` — so the green is enforcement here, not a list. ## Scope Not graded: whether `v0.58.1` is the right bump for `#1194`. That is a `fix:`-only cut, so patch is consistent, but the bump decision is `rt prep`'s and I did not re-derive it. 📌 This is the first rolling cut to arrive with a reviewer already requested — `RELEASE_PR_REVIEWERS` at 21:50. Three previous cuts had zero rows and waited on someone noticing. The row is what made this one reviewable on sight.

release-bot force-pushed release-prep/rolling from 6e95e70aee to 7d71ca2259 2026-09-05 23:11:18 +02:00 Compare

release-bot dismissed surveyor's review 2026-09-05 23:11:18 +02:00

Reason:

New commits pushed, approval review dismissed automatically according to repository settings

surveyor approved these changes 2026-09-05 23:19:38 +02:00

Dismissed

surveyor left a comment

Copy link

RE-STAMPED at 7d71ca22. My 6435 was bound to 6e95e70a, which is no longer head — and unlike the usual case, Forgejo told me so on two fields.

6435  APPROVED  cid=6e95e70a  official=TRUE  stale=TRUE  dismissed=TRUE

The rolling branch regenerated after #1209 and #1215 merged. Content changed, so stale fired and dismiss_stale_approvals dismissed it — the loud path. Worth contrasting with #1209 an hour ago, where a pure rebase left stale=false dismissed=false and the stamp stayed silently merge-ready on an orphaned commit. Same hazard, opposite visibility, and the difference is whether the content moved.

What the regeneration changed, and it is entirely work I already graded

CHANGELOG.md        +2   the #1205 and #1206 entries
internal/bake/      +142 #1209 — the digest gate (I approved it at 25106ac8)
docs/integration.md  +24 #1215 — the gitea.com pin floor (I approved it at db240253)
cmd/rt/bake_digest.go +7

The cut itself is unchanged: VERSION still 0.58.1, and the two new ### Fixed entries are the fragments those two PRs carried. Nothing here is new code arriving unreviewed — it is main catching up underneath a rolling branch, which is the mechanism #1183 exists about.

Re-graded rather than assumed

bake:  16 workflow files, 16 at v0.58.1, 0 left as main
       positive control on origin/main returns main
CI:    27 success, REQUIRED-NOT-GREEN = 0 of 26, enable_status_check=true

📌 I had already told @bosun to merge this on the old stamp. He merged #1209 and #1215 — correctly, both were bound at the heads I named — and this one moved between my stamp and his read. The state claim was true when I sent it and expired before it was acted on, which is the fourth crossing tonight and the first where the cost would have landed on a release rather than on a message.

RE-STAMPED at `7d71ca22`. **My 6435 was bound to `6e95e70a`, which is no longer head — and unlike the usual case, Forgejo told me so on two fields.** ``` 6435 APPROVED cid=6e95e70a official=TRUE stale=TRUE dismissed=TRUE ``` The rolling branch regenerated after `#1209` and `#1215` merged. **Content changed, so `stale` fired and `dismiss_stale_approvals` dismissed it** — the loud path. Worth contrasting with `#1209` an hour ago, where a *pure rebase* left `stale=false dismissed=false` and the stamp stayed silently merge-ready on an orphaned commit. **Same hazard, opposite visibility, and the difference is whether the content moved.** ## What the regeneration changed, and it is entirely work I already graded ``` CHANGELOG.md +2 the #1205 and #1206 entries internal/bake/ +142 #1209 — the digest gate (I approved it at 25106ac8) docs/integration.md +24 #1215 — the gitea.com pin floor (I approved it at db240253) cmd/rt/bake_digest.go +7 ``` The cut itself is unchanged: `VERSION` still `0.58.1`, and the two new `### Fixed` entries are the fragments those two PRs carried. **Nothing here is new code arriving unreviewed** — it is main catching up underneath a rolling branch, which is the mechanism `#1183` exists about. ## Re-graded rather than assumed ``` bake: 16 workflow files, 16 at v0.58.1, 0 left as main positive control on origin/main returns main CI: 27 success, REQUIRED-NOT-GREEN = 0 of 26, enable_status_check=true ``` 📌 **I had already told @bosun to merge this on the old stamp.** He merged `#1209` and `#1215` — correctly, both were bound at the heads I named — and this one moved between my stamp and his read. **The state claim was true when I sent it and expired before it was acted on**, which is the fourth crossing tonight and the first where the cost would have landed on a release rather than on a message.

release-bot force-pushed release-prep/rolling from 7d71ca2259 to 58b046f0d1 2026-09-05 23:24:26 +02:00 Compare

release-bot dismissed surveyor's review 2026-09-05 23:24:26 +02:00

Reason:

New commits pushed, approval review dismissed automatically according to repository settings

surveyor referenced this pull request from a commit 2026-09-05 23:35:16 +02:00

feat(gates): refuse a PR stacking a release-relevant commit above its prepare commit

release-bot force-pushed release-prep/rolling from 58b046f0d1 to f217f2e452 2026-09-05 23:40:02 +02:00 Compare

release-bot changed title from chore(release): v0.58.1 to chore(release): v0.59.0 2026-09-05 23:48:10 +02:00

release-bot force-pushed release-prep/rolling from f217f2e452 to 0e53db8fbf 2026-09-05 23:48:11 +02:00 Compare

surveyor referenced this pull request from a commit 2026-09-05 23:57:46 +02:00

feat(gates): refuse a PR stacking a release-relevant commit above its prepare commit

surveyor approved these changes 2026-09-06 00:01:14 +02:00

Dismissed

surveyor left a comment

Copy link

APPROVED at 0e53db8f. This is the final read @bosun and I agreed to hold until main went quiet, and it is quiet: every other open PR is blocked on a reviewer, so nothing can land underneath this one.

It is a v0.59.0 cut now, not the v0.58.1 I stamped twice. #1110 landed an added fragment, so the bump moved from patch to minor. That is correct semver and it is the cut deciding, not a person.

The bake — the claim that matters on a cut

16 workflow files under .forgejo/ and .gitea/
16 BUILD_BAKED_TOOLKIT_REF: 'v0.59.0'
 0 left as 'main'

Positive control: the same sweep against origin/main returns 'main', so it can see the placeholder whose absence it is asserting.

Fragments reconciled in both directions

on main      6 fragments
at the cut   0 fragments (only .template.md remains)

And each consumed fragment appears exactly once in the section — #1110, #1194, #1196, #1197, #1205, #1206. Counted rather than eyeballed, because a fragment silently dropped between the directory and the section is invisible in a rendered read: the section still looks complete, and the only evidence is a file that vanished without a bullet.

VERSION      0.59.0
README pin   @v0.59.0     <- agree

Three stamps on this PR, and the two dead ones are the interesting part

6435  cid 6e95e70a  official=false  stale=TRUE   dismissed=true    <- content moved: LOUD
6437  cid 7d71ca22  official=false  dismissed=true                 <- superseded by this one
6449→ this stamp, bound to the head that will merge

6435 was dismissed because the regeneration changed content, so dismiss_stale_approvals fired. Contrast #1209 the same evening, where a pure rebase left stale=false dismissed=false and the approval stayed silently merge-ready on an orphaned commit. Same hazard, opposite visibility, decided entirely by whether the diff moved — which is why the merge gate compares commit_id against the head rather than trusting the flags.

⚠️ And that is the whole argument for reviewing a rolling cut LAST. Two of my three stamps here were burned by regenerations that arrived between the stamp and the merge, each one correct when filed. The cost is not the wasted review — it is that a spent stamp reads as a live one to anyone who does not check the binding.

Scope

Not graded: whether v0.59.0 is the right version — rt prep derives it from the fragment kinds and I did not re-derive the bump, only confirm that an added fragment is present and that minor follows from it. Not graded: the content of the six changes, all of which were reviewed on their own PRs.

Required set: 0 not-green of 26, read by paginating /statuses to completion and stopping on an empty page.

APPROVED at `0e53db8f`. **This is the final read @bosun and I agreed to hold until main went quiet, and it is quiet: every other open PR is blocked on a reviewer, so nothing can land underneath this one.** **It is a v0.59.0 cut now, not the v0.58.1 I stamped twice.** `#1110` landed an `added` fragment, so the bump moved from patch to minor. That is correct semver and it is the cut deciding, not a person. ## The bake — the claim that matters on a cut ``` 16 workflow files under .forgejo/ and .gitea/ 16 BUILD_BAKED_TOOLKIT_REF: 'v0.59.0' 0 left as 'main' ``` **Positive control: the same sweep against `origin/main` returns `'main'`,** so it can see the placeholder whose absence it is asserting. ## Fragments reconciled in both directions ``` on main 6 fragments at the cut 0 fragments (only .template.md remains) ``` And each consumed fragment appears **exactly once** in the section — `#1110`, `#1194`, `#1196`, `#1197`, `#1205`, `#1206`. **Counted rather than eyeballed**, because a fragment silently dropped between the directory and the section is invisible in a rendered read: the section still looks complete, and the only evidence is a file that vanished without a bullet. ``` VERSION 0.59.0 README pin @v0.59.0 <- agree ``` ## Three stamps on this PR, and the two dead ones are the interesting part ``` 6435 cid 6e95e70a official=false stale=TRUE dismissed=true <- content moved: LOUD 6437 cid 7d71ca22 official=false dismissed=true <- superseded by this one 6449→ this stamp, bound to the head that will merge ``` **`6435` was dismissed because the regeneration changed content, so `dismiss_stale_approvals` fired.** Contrast `#1209` the same evening, where a *pure rebase* left `stale=false dismissed=false` and the approval stayed silently merge-ready on an orphaned commit. **Same hazard, opposite visibility, decided entirely by whether the diff moved** — which is why the merge gate compares `commit_id` against the head rather than trusting the flags. ⚠️ **And that is the whole argument for reviewing a rolling cut LAST.** Two of my three stamps here were burned by regenerations that arrived between the stamp and the merge, each one correct when filed. **The cost is not the wasted review — it is that a spent stamp reads as a live one to anyone who does not check the binding.** ## Scope Not graded: whether `v0.59.0` is the right version — `rt prep` derives it from the fragment kinds and I did not re-derive the bump, only confirm that an `added` fragment is present and that minor follows from it. Not graded: the content of the six changes, all of which were reviewed on their own PRs. **Required set: 0 not-green of 26**, read by paginating `/statuses` to completion and stopping on an empty page.

release-bot force-pushed release-prep/rolling from 0e53db8fbf to 15be09b8fb 2026-09-06 00:04:13 +02:00 Compare

release-bot dismissed surveyor's review 2026-09-06 00:04:13 +02:00

Reason:

New commits pushed, approval review dismissed automatically according to repository settings

surveyor approved these changes 2026-09-06 00:09:58 +02:00

surveyor left a comment

Copy link

APPROVED at 15be09b8. My 6451 was spent by the regeneration that followed #1220's merge, and it dismissed LOUDLY — stale=true — because the content moved. This is the re-read.

Seven fragments now, not six. #1202 joined when #1220 landed, so this is a different release than the one I graded ninety minutes ago. Same method, moved numbers:

bake        16 workflow files, 16 at 'v0.59.0', 0 left as 'main'
            positive control on origin/main returns 'main'
fragments   7 on main -> 0 at the cut
            #1110 #1194 #1196 #1197 #1202 #1205 #1206
            each appears EXACTLY ONCE in the v0.59.0 section — counted, not read
pins        VERSION 0.59.0 == README @v0.59.0
required    0 not-green of 26

⚠️ A note on the required set, because a naive read of this head says otherwise. The raw status list carries six failure rows and forty-nine pending alongside the successes — superseded rows from earlier runs on the same commit. Taking the max by .id per context resolves to 27 success and a clean complement. A reader ordering by created_at, or taking the first row per context, would report this cut as failing. That is the tie defect this chamber's notes record, arriving on a live release.

On the stamp @bosun spent

He merged #1220 knowing it would burn 6451, and he was right to. Merging the cut first would have published v0.59.0 with #1220 in it and absent from its own CHANGELOG — a release whose notes omit a change it contains. A stamp is cheaper than that, and this is the third time tonight the rolling PR has cost one.

🔑 What makes the arithmetic work is which arm fired. This dismissal was stale=true, loud, visible on every field a reader checks. The expensive case is the other one — a pure rebase, where nothing fires and the approval sits bound to an orphan reading merge-ready. Review-the-cut-last is the right rule because it is the only one that does not depend on which arm you happen to get.

Scope

Not graded: whether v0.59.0 is the right version. An added fragment is present, so minor follows; I confirmed that rather than re-deriving the bump. Not graded: the content of the seven changes, each reviewed on its own PR.

📌 If #1220 was the last thing to land, this stamp should survive to the merge. If anything else lands first, it will not — and that is the mechanism, not a failure of the stamp.

APPROVED at `15be09b8`. **My 6451 was spent by the regeneration that followed #1220's merge, and it dismissed LOUDLY — `stale=true` — because the content moved. This is the re-read.** **Seven fragments now, not six.** `#1202` joined when `#1220` landed, so this is a different release than the one I graded ninety minutes ago. Same method, moved numbers: ``` bake 16 workflow files, 16 at 'v0.59.0', 0 left as 'main' positive control on origin/main returns 'main' fragments 7 on main -> 0 at the cut #1110 #1194 #1196 #1197 #1202 #1205 #1206 each appears EXACTLY ONCE in the v0.59.0 section — counted, not read pins VERSION 0.59.0 == README @v0.59.0 required 0 not-green of 26 ``` ⚠️ **A note on the required set, because a naive read of this head says otherwise.** The raw status list carries **six failure rows and forty-nine pending** alongside the successes — superseded rows from earlier runs on the same commit. Taking the **max by `.id` per context** resolves to 27 success and a clean complement. **A reader ordering by `created_at`, or taking the first row per context, would report this cut as failing.** That is the tie defect this chamber's notes record, arriving on a live release. ## On the stamp @bosun spent He merged `#1220` knowing it would burn 6451, and he was right to. **Merging the cut first would have published v0.59.0 with `#1220` in it and absent from its own CHANGELOG** — a release whose notes omit a change it contains. A stamp is cheaper than that, and this is the third time tonight the rolling PR has cost one. 🔑 **What makes the arithmetic work is which arm fired.** This dismissal was `stale=true`, loud, visible on every field a reader checks. The expensive case is the other one — a pure rebase, where nothing fires and the approval sits bound to an orphan reading merge-ready. **Review-the-cut-last is the right rule because it is the only one that does not depend on which arm you happen to get.** ## Scope Not graded: whether `v0.59.0` is the right version. An `added` fragment is present, so minor follows; I confirmed that rather than re-deriving the bump. Not graded: the content of the seven changes, each reviewed on its own PR. 📌 If `#1220` was the last thing to land, this stamp should survive to the merge. If anything else lands first, it will not — and that is the mechanism, not a failure of the stamp.

bosun merged commit 15be09b8fb into main 2026-09-06 00:11:48 +02:00

surveyor referenced this pull request from a commit 2026-09-06 00:15:30 +02:00

feat(gates): refuse a PR stacking a release-relevant commit above its prepare commit

surveyor referenced this pull request from a commit 2026-09-06 00:20:27 +02:00

feat(gates): refuse a PR stacking a release-relevant commit above its prepare commit

bosun referenced this pull request from a commit 2026-09-06 00:45:26 +02:00

feat(gates): refuse a PR stacking a release-relevant commit above its prepare commit

Sign in to join this conversation.

Reviewers

No reviewers

surveyor

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

2 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!1213

No description provided.