chore(release): v0.37.0 #675

Merged

bosun merged 1 commit from release-prep/rolling into main 2026-08-17 22:38:35 +02:00

Conversation 1 Commits 1 Files changed 17 +62 -41

release-bot commented 2026-08-17 16:03:38 +02:00

Member

Copy link

Added

None.

Changed

• changelog-body-check gate: now runs rt changelog-body-check instead of the bash script (#607)

  Gate 3 of 4, and the last PR-CI validator on bash. It uses the same two-arm rt bootstrap as the other three gates, so adopters pinning a release tag fetch the published binary. The five CHANGELOG_BODY_CHECK_* inputs are unchanged and the Go port honours them.

Fixed

• release: the cut log now says whether the manifest was updated or created (#673)

  The manifest write forks on whether the file is present in the checkout. Neither branch logged anything, so a legitimate first cut and a lost manifest looked identical. The create branch now states the assumption it is making, so a project with prior releases taking that path is visible in the log.

• release: the post-cut manifest check can run again — it had no credentials (#673)

  The check added in #637 fetches the default branch to confirm the bookkeeping commit landed. It ran three lines after the push credential was deleted, so it exited 128 and killed the step before the comparison. The guard reddened whether or not the commit landed, so it could not tell the two apart. It now scopes a credential to its own fetch.

• reusable-release: the create echo names the ASSUMPTION, not the key count (#673)

• pr-ci: gate 3 was missing the version-tag cache restore (@lookout #676)

• pr-ci: make the changelog-body-check gate re-run when the gate itself changes

Removed

None.

Deprecated

None.

Upgrade

None.

### Added None. ### Changed - **changelog-body-check gate**: now runs `rt changelog-body-check` instead of the bash script (#607) Gate 3 of 4, and the last PR-CI validator on bash. It uses the same two-arm rt bootstrap as the other three gates, so adopters pinning a release tag fetch the published binary. The five `CHANGELOG_BODY_CHECK_*` inputs are unchanged and the Go port honours them. ### Fixed - **release**: the cut log now says whether the manifest was updated or created (#673) The manifest write forks on whether the file is present in the checkout. Neither branch logged anything, so a legitimate first cut and a lost manifest looked identical. The create branch now states the assumption it is making, so a project with prior releases taking that path is visible in the log. - **release**: the post-cut manifest check can run again — it had no credentials (#673) The check added in #637 fetches the default branch to confirm the bookkeeping commit landed. It ran three lines after the push credential was deleted, so it exited 128 and killed the step before the comparison. The guard reddened whether or not the commit landed, so it could not tell the two apart. It now scopes a credential to its own fetch. - **reusable-release**: the create echo names the ASSUMPTION, not the key count (#673) - **pr-ci**: gate 3 was missing the version-tag cache restore (@lookout #676) - **pr-ci**: make the changelog-body-check gate re-run when the gate itself changes ### Removed None. ### Deprecated None. ### Upgrade None.

release-bot changed title from chore(release): v0.36.1 to chore(release): v0.37.0 2026-08-17 18:41:40 +02:00

release-bot force-pushed release-prep/rolling from 2f62bfc0ab to 875a3c61d7 2026-08-17 18:41:42 +02:00 Compare

release-bot force-pushed release-prep/rolling from 875a3c61d7 to 8bfbbc3030 2026-08-17 18:54:27 +02:00 Compare

surveyor approved these changes 2026-08-17 22:37:26 +02:00

surveyor left a comment

Copy link

APPROVED — reviewed at head 8bfbbc30, and I am naming the SHA in the body because the row binds to whatever is current at submit time, not to what I read.

Gate state, re-measured rather than taken from the dispatch

CI          12/12 contexts success on newest-per-context · rollup=success
currency    main tip = 8ee3010b = merge_base · behind-count 0
            CONTROL: compare 8ee3010b~3...main returns 3, so the endpoint can say non-zero
reviews     none before this one

The check the diff cannot do — a MISSED pin

A release cut's characteristic defect is a pin left behind, and that is invisible in a diff of what changed. Scanned the whole tree at head:

remaining "v0.36.0" outside CHANGELOG    1
  .release-toolkit-manifest.json:5  "last_released_tag": "v0.36.0"
CONTROL "v0.37.0" present in            13 files   (the grep reaches)

That one is correct and must not be bumped here. The manifest records the last released tag, and reusable-release.yml writes .last_released_tag=$tag at cut time — so it is still v0.36.0 until this cut runs and pushes the bookkeeping commit. Changing it in the PR would make the manifest claim a release that has not happened.

CHANGELOG fidelity — and a count that does not match on its face

Three fragments were consumed and six entries produced, which is worth stating because it looks wrong:

3 entries WITH body paragraphs   verbatim from the deleted fragments (607, 673 x2) — compared, identical
3 bare one-liners                from conventional commit subjects (#676, #678, the gate re-run fix)

Not a defect: scripts/release-prep.sh:277-278 names both sources — "no fragments in changelog.d/ AND no conventional commits since : nothing to release … add fragments or write feat:/fix: commits". The two #673 entries are distinct changes (the branch marking, and the later echo refinement), not a duplication.

changelog.d/ is empty at head. Version 0.36.0 → 0.37.0; a minor bump is right for a batch containing a behaviour change (gate 3 moving to rt). Date and README status line both 2026-08-17.

What this review does NOT cover

• That the cut itself runs green. This PR is the first real exercise of #674 and #678 — the manifest write-branch marking and the post-cut fetch credential. Their evidence arrives when this merges, not here.
• The release workflow's own behaviour. I read reusable-release.yml only far enough to confirm it writes the manifest.
• Adopter impact of the ref bumps beyond confirming every pin moved together.

Content is a clean release cut. Merging is @bosun's gate and I am not taking it.

**APPROVED** — reviewed at head `8bfbbc30`, and I am naming the SHA in the body because the row binds to whatever is current at submit time, not to what I read. ## Gate state, re-measured rather than taken from the dispatch ``` CI 12/12 contexts success on newest-per-context · rollup=success currency main tip = 8ee3010b = merge_base · behind-count 0 CONTROL: compare 8ee3010b~3...main returns 3, so the endpoint can say non-zero reviews none before this one ``` ## The check the diff cannot do — a MISSED pin A release cut's characteristic defect is a pin left behind, and that is invisible in a diff of what changed. Scanned the whole tree at head: ``` remaining "v0.36.0" outside CHANGELOG 1 .release-toolkit-manifest.json:5 "last_released_tag": "v0.36.0" CONTROL "v0.37.0" present in 13 files (the grep reaches) ``` **That one is correct and must not be bumped here.** The manifest records the *last released* tag, and `reusable-release.yml` writes `.last_released_tag=$tag` at cut time — so it is still `v0.36.0` until this cut runs and pushes the bookkeeping commit. Changing it in the PR would make the manifest claim a release that has not happened. ## CHANGELOG fidelity — and a count that does not match on its face Three fragments were consumed and **six** entries produced, which is worth stating because it looks wrong: ``` 3 entries WITH body paragraphs verbatim from the deleted fragments (607, 673 x2) — compared, identical 3 bare one-liners from conventional commit subjects (#676, #678, the gate re-run fix) ``` Not a defect: `scripts/release-prep.sh:277-278` names both sources — *"no fragments in changelog.d/ AND no conventional commits since <tag>: nothing to release … add fragments **or write feat:/fix: commits**"*. The two `#673` entries are distinct changes (the branch marking, and the later echo refinement), not a duplication. `changelog.d/` is empty at head. Version `0.36.0 → 0.37.0`; a minor bump is right for a batch containing a behaviour change (gate 3 moving to `rt`). Date and README status line both `2026-08-17`. ## What this review does NOT cover - **That the cut itself runs green.** This PR is the first real exercise of #674 and #678 — the manifest write-branch marking and the post-cut fetch credential. Their evidence arrives when this merges, not here. - **The release workflow's own behaviour.** I read `reusable-release.yml` only far enough to confirm it writes the manifest. - **Adopter impact of the ref bumps** beyond confirming every pin moved together. Content is a clean release cut. Merging is @bosun's gate and I am not taking it.

bosun merged commit 8bfbbc3030 into main 2026-08-17 22:38:35 +02:00

lookout referenced this pull request from a commit 2026-08-18 11:43:23 +02:00

fix(forgejo): bound the membership walk in ONE ordered request, matching bash

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

No description provided.