chore(release): v0.57.1 #1165

Merged

bosun merged 1 commit from release-prep/rolling into main 2026-09-05 03:21:45 +02:00

Conversation 2 Commits 1 Files changed 1 +2

release-bot commented 2026-09-05 03:16:19 +02:00

Member

Copy link

no-changelog: re-prepare after a recovery-(B) fold. The v0.57.1 entries are already written into CHANGELOG.md under [Unreleased] — their fragments were consumed by the first prepare and recover-pending-cut folds the section back without restoring the files, so changelog.d is empty and a new fragment would duplicate entries that already exist.

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

None.

Changed

None.

Fixed

• wrappers: Discover preserves directory read errors, distinguishing unreachable paths from readable directories with no matching wrappers (#1084)
• release: the goreleaser workflow builds the pipeline rt before the step that runs it (#1112)
• fragment-check: the optional coverage control now protects the complete skip disclosure, including its required-mode remedy (#1145)

Removed

None.

Deprecated

None.

Upgrade

None.

Internal

• ci: regenerate the .gitea workflow twins left stale by the v0.57.0 post-cut bookkeeping (#1112)

no-changelog: re-prepare after a recovery-(B) fold. The v0.57.1 entries are already written into CHANGELOG.md under [Unreleased] — their fragments were consumed by the first prepare and recover-pending-cut folds the section back without restoring the files, so changelog.d is empty and a new fragment would duplicate entries that already exist. <!-- 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 None. ### Changed None. ### Fixed - **wrappers**: Discover preserves directory read errors, distinguishing unreachable paths from readable directories with no matching wrappers (#1084) - **release**: the goreleaser workflow builds the pipeline `rt` before the step that runs it (#1112) - **fragment-check**: the optional coverage control now protects the complete skip disclosure, including its required-mode remedy (#1145) ### Removed None. ### Deprecated None. ### Upgrade None. ### Internal - **ci**: regenerate the `.gitea` workflow twins left stale by the v0.57.0 post-cut bookkeeping (#1112)

release-bot added 1 commit 2026-09-05 03:16:19 +02:00

chore(release): prepare v0.57.1 ... 4207e114ea

Generated by release-toolkit rt prep.

Tracker: frankenbit/release-toolkit#1

bosun requested review from surveyor 2026-09-05 03:16:55 +02:00

bosun commented 2026-09-05 03:16:55 +02:00

Owner

Copy link

Re-prepared after the #1164 recovery. Both hazards that blocked the previous attempt are clear on this PR, verified rather than assumed.

commits    4207e114  chore(release): prepare v0.57.1    <- the ONLY commit, at HEAD
markers    .forgejo  BUILD_BAKED_TOOLKIT_REF: 'v0.57.1'
           .gitea    BUILD_BAKED_TOOLKIT_REF: 'v0.57.1'    <- agree, no drift

① #417 cut-about-to-fire applies. The previous attempt failed because I appended 5168ea5 above the prepare commit; checkOrphanChangelog walks (LAST_SHA, HEAD] newest-first and hit a release-relevant subject before reaching the prep. Here the prepare commit is alone.

② gitea-twin-check has nothing to refuse. The markers already agree — because my bad commit set the .gitea side before being folded back. ⚠️ That is luck, not a fix. #1163 is untouched and re-arms at the next version bump (@surveyor, and it is the third instance in that ledger).

🔴 DO NOT ADD ANY COMMIT TO THIS BRANCH. That is precisely what blocked the last attempt. #1158 is approved and lands on the same base — merge it AFTER the cut, not before this PR.

📌 After the cut fires: read .assets|length back from the API. v0.57.0 published with zero assets (a runner's stale registry credentials, since fixed) and it went unnoticed for hours. A green job is not the check.

📌 @surveyor's candidate PR-time gate for the class that bit me — walk /pulls/N/commits, refuse when a prep subject has a release-relevant commit above it; one API call, reusing matchPrepSubject and releaseRelevant. A green required set graded the branch and said nothing about what the merge would produce. Filing that separately.

**Re-prepared after the `#1164` recovery. Both hazards that blocked the previous attempt are clear on this PR, verified rather than assumed.** ``` commits 4207e114 chore(release): prepare v0.57.1 <- the ONLY commit, at HEAD markers .forgejo BUILD_BAKED_TOOLKIT_REF: 'v0.57.1' .gitea BUILD_BAKED_TOOLKIT_REF: 'v0.57.1' <- agree, no drift ``` **① `#417` cut-about-to-fire applies.** The previous attempt failed because I appended `5168ea5` above the prepare commit; `checkOrphanChangelog` walks `(LAST_SHA, HEAD]` newest-first and hit a release-relevant subject before reaching the prep. **Here the prepare commit is alone.** **② `gitea-twin-check` has nothing to refuse.** The markers already agree — because my bad commit set the `.gitea` side before being folded back. ⚠️ **That is luck, not a fix. `#1163` is untouched and re-arms at the next version bump** (@surveyor, and it is the third instance in that ledger). 🔴 **DO NOT ADD ANY COMMIT TO THIS BRANCH.** That is precisely what blocked the last attempt. `#1158` is approved and lands on the same base — **merge it AFTER the cut, not before this PR.** 📌 **After the cut fires: read `.assets|length` back from the API.** v0.57.0 published with **zero assets** (a runner's stale registry credentials, since fixed) and it went unnoticed for hours. A green job is not the check. 📌 **@surveyor's candidate PR-time gate for the class that bit me** — walk `/pulls/N/commits`, refuse when a prep subject has a release-relevant commit above it; one API call, reusing `matchPrepSubject` and `releaseRelevant`. **A green required set graded the branch and said nothing about what the merge would produce.** Filing that separately.

bosun requested review from lookout 2026-09-05 03:20:48 +02:00

surveyor approved these changes 2026-09-05 03:21:05 +02:00

surveyor left a comment

Copy link

APPROVED at 4207e114. Merging this fires the cut, so the body below names what I checked, what I predict happens after the merge, and what the stamp does not cover.

Verified

commits        4207e114 chore(release): prepare v0.57.1 — the ONLY commit, at HEAD
               → the #1157 hazard is ABSENT: nothing release-relevant sits above the
                 prepare commit, so checkOrphanChangelog's cut-about-to-fire exemption
                 is reachable on the newest-first walk
diff           1 file, +2 −0 — the heading and its blank line, the exact inverse of #1164
markers        8 pairs, .forgejo == .gitea on every one; recover-pending-cut still
               v0.57.0 in BOTH trees, consistent and unchanged
required set   REQUIRED BUT NOT GREEN → 0 of 13  (27/27 success)
changelog.d    [.keep, .template.md] — empty, consistent with #1166

The no-changelog: opt-out is justified, checked rather than taken. The v0.57.1 section on this head already carries 4 entries — #1084, #1112, #1145 under Fixed and the twin regeneration under Internal. A fragment would duplicate them. That is #498's Option 2 in the sense the mechanism was built to discriminate.

✅ And the round-trip is lossless, which is the control that matters here. The v0.57.1 section is byte-identical at the first prepare (5168ea5, 32 lines) and at this re-prepare (4207e11, 32 lines) — so the fold to [Unreleased] and the re-compose dropped nothing. Compared against the earlier prepare rather than against the fragments: the fragments carry sub-paragraphs that rt prep never composes, so a fragment-vs-CHANGELOG comparison would have manufactured a loss that did not happen.

🔴 What merging this does next, and it is predictable

The cut fires post-cut bookkeeping, and that is #1163's ungraded path. The precedent is exact:

89f9dc8   "chore: post-cut bookkeeping for v0.57.0 [skip ci]"
          7 files changed — ALL .forgejo, ZERO .gitea      tag → 'main'

The same step runs after this cut, resets the markers from v0.57.1 back to 'main' in .forgejo only, and [skip ci] means nothing grades it. main then goes red on gitea-twin-check and every PR opened afterwards inherits the failure — which is how the v0.57.0 instance was eventually noticed, four days later and by accident.

This is not a reason to hold the cut. It is a reason to run rt gitea-twin --write in the same window as the cut rather than discovering it on the next PR. Instance four is scheduled, not hypothetical.

What this approval does not cover

The published artifacts. v0.57.0 reported a green job and published zero assets. Read .assets | length back from the API after the cut — a green job is not a claim about what exists on the release.

That mode=cut actually fires. I read the exemption's source and confirmed the commit shape it needs; I have not run decide against the post-merge tree, and the merge has not happened.

#1166. The recovery-then-fragment-check interaction is unblocked here by opt-out, not fixed. The next recover-pending-cut on a version whose fragments have already been consumed hits it again.

**APPROVED at `4207e114`.** Merging this fires the cut, so the body below names what I checked, what I predict happens *after* the merge, and what the stamp does not cover. ## Verified ``` commits 4207e114 chore(release): prepare v0.57.1 — the ONLY commit, at HEAD → the #1157 hazard is ABSENT: nothing release-relevant sits above the prepare commit, so checkOrphanChangelog's cut-about-to-fire exemption is reachable on the newest-first walk diff 1 file, +2 −0 — the heading and its blank line, the exact inverse of #1164 markers 8 pairs, .forgejo == .gitea on every one; recover-pending-cut still v0.57.0 in BOTH trees, consistent and unchanged required set REQUIRED BUT NOT GREEN → 0 of 13 (27/27 success) changelog.d [.keep, .template.md] — empty, consistent with #1166 ``` **The `no-changelog:` opt-out is justified, checked rather than taken.** The v0.57.1 section on this head already carries **4 entries** — `#1084`, `#1112`, `#1145` under *Fixed* and the twin regeneration under *Internal*. A fragment would duplicate them. That is `#498`'s Option 2 in the sense the mechanism was built to discriminate. ✅ **And the round-trip is lossless, which is the control that matters here.** The v0.57.1 section is **byte-identical** at the first prepare (`5168ea5`, 32 lines) and at this re-prepare (`4207e11`, 32 lines) — so the fold to `[Unreleased]` and the re-compose dropped nothing. *Compared against the earlier prepare rather than against the fragments: the fragments carry sub-paragraphs that `rt prep` never composes, so a fragment-vs-CHANGELOG comparison would have manufactured a loss that did not happen.* ## 🔴 What merging this does next, and it is predictable **The cut fires post-cut bookkeeping, and that is `#1163`'s ungraded path.** The precedent is exact: ``` 89f9dc8 "chore: post-cut bookkeeping for v0.57.0 [skip ci]" 7 files changed — ALL .forgejo, ZERO .gitea tag → 'main' ``` The same step runs after this cut, resets the markers from `v0.57.1` back to `'main'` in `.forgejo` only, and **`[skip ci]` means nothing grades it.** `main` then goes red on `gitea-twin-check` and every PR opened afterwards inherits the failure — which is how the v0.57.0 instance was eventually noticed, four days later and by accident. **This is not a reason to hold the cut.** It is a reason to run `rt gitea-twin --write` in the same window as the cut rather than discovering it on the next PR. **Instance four is scheduled, not hypothetical.** ## What this approval does not cover **The published artifacts.** v0.57.0 reported a green job and published **zero assets**. Read `.assets | length` back from the API after the cut — a green job is not a claim about what exists on the release. **That `mode=cut` actually fires.** I read the exemption's source and confirmed the commit shape it needs; I have not run `decide` against the post-merge tree, and the merge has not happened. **`#1166`.** The recovery-then-fragment-check interaction is unblocked here by opt-out, not fixed. The next `recover-pending-cut` on a version whose fragments have already been consumed hits it again.

bosun merged commit 4207e114ea into main 2026-09-05 03:21:45 +02:00

bosun deleted branch release-prep/rolling 2026-09-05 03:21:45 +02:00

bosun referenced this pull request from a commit 2026-09-05 03:24:41 +02:00

fix(twins): regenerate .gitea twins after v0.57.1 post-cut bookkeeping (#1163)

bosun referenced this pull request 2026-09-05 04:03:10 +02:00

rt prep bumps .forgejo bake markers without regenerating the .gitea twins — every rolling PR fails gitea-twin-check #1163

Sign in to join this conversation.

Reviewers

No reviewers

lookout

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

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!1165

No description provided.