chore(release): v0.39.0 #718

Merged

bosun merged 1 commit from release-prep/rolling into main 2026-08-19 08:38:58 +02:00

Conversation 4 Commits 1 Files changed 20 +83 -65

release-bot commented 2026-08-18 23:54:50 +02:00

Member

Copy link

Added

None.

Changed

• fragment-check: grades changelog density and FAILS on a violation, so a dense fragment is caught on its own PR instead of at cut time (#621)

  The density rules were already enforced, but only against the composed CHANGELOG.md. rt prep recreates that file from the fragments on every compose, so a fix applied there is regenerated away. This grades the same checks, from the same implementation, at the layer where a fix survives. Set density: 'false' to opt out. Pass the five threshold inputs to match your changelog-body-check wiring, or the two layers can disagree.

Fixed

• changelog-body-check: check 7 now names every over-threshold sentence, not just the longest one in each paragraph (#621)

  A second long sentence in the same paragraph used to be invisible. A fixer who cleared the named list and pushed then got a fresh FAIL that read as a new problem. Measured at eight over-threshold sentences reported as five. Verdicts are unchanged: the same text fails, and the report is now the complete work list.

• changelog-body-check: check 3 no longer refuses a dependency pin that outranks the version being cut (#658)

  A pin naming another repository states a fact about a shipped release. Check 3 read every @vX.Y.Z as a forward reference, so a consumer whose dependencies outranked it could not cut at all. Repo identity now comes from GITHUB_REPOSITORY or FORGEJO_REPOSITORY.

  The match is a prefix, so the Actions uses: path form is still caught as a self-reference. A bare pin carrying no owner is still checked, which is the deliberate safe direction. With neither variable set the behaviour is unchanged. The PASS line now names the pins it exempted, and a FAIL names the pin rather than only its version.

A cut-safeguard refusal now says what it refused about. The decline path emits
safeguard_version and prep_sha alongside safeguard_fail.

The workflow has named all three in its ::error:: since #663 and consumed all
three as env vars, but only one was ever emitted. Operators read a prepare commit for v? … Prepare commit graded: unknown while the same log printed both values six
lines above.

• prep: --dry-run now names the working-tree paths it changed, and its help text stops calling itself preview-only (#700)

  The flag skips the branch checkout, commit, push and PR call. It still rewrites the changelog, bumps version_files, runs post_bump_hooks and deletes consumed fragments, so a run read as side-effect-free left a dirty tree. Staged paths are reported separately because git checkout -- . does not restore them. The disclosure is derived from git rather than from a fixed list.

• ci: the positive control must survive -e when the gate refuses

• changelog: split the #658 fragment paragraph that fails the density gate

• prep: the staged-class undo verb deleted uncommitted operator work

• changelog: the #700 fragment repeated the claim the PR exists to correct

• prep: give a COMPLETE undo for staged paths, and stop claiming git writes are skipped

Removed

None.

Deprecated

None.

Upgrade

None.

Internal

• tests: Bats CI now prints captured command output when an assertion fails, while keeping passing-test output hidden (#686)

### Added None. ### Changed - **fragment-check**: grades changelog density and FAILS on a violation, so a dense fragment is caught on its own PR instead of at cut time (#621) The density rules were already enforced, but only against the composed `CHANGELOG.md`. `rt prep` recreates that file from the fragments on every compose, so a fix applied there is regenerated away. This grades the same checks, from the same implementation, at the layer where a fix survives. Set `density: 'false'` to opt out. Pass the five threshold inputs to match your `changelog-body-check` wiring, or the two layers can disagree. ### Fixed - **changelog-body-check**: check 7 now names every over-threshold sentence, not just the longest one in each paragraph (#621) A second long sentence in the same paragraph used to be invisible. A fixer who cleared the named list and pushed then got a fresh FAIL that read as a new problem. Measured at eight over-threshold sentences reported as five. Verdicts are unchanged: the same text fails, and the report is now the complete work list. - **changelog-body-check**: check 3 no longer refuses a dependency pin that outranks the version being cut (#658) A pin naming another repository states a fact about a shipped release. Check 3 read every `@vX.Y.Z` as a forward reference, so a consumer whose dependencies outranked it could not cut at all. Repo identity now comes from `GITHUB_REPOSITORY` or `FORGEJO_REPOSITORY`. The match is a prefix, so the Actions `uses:` path form is still caught as a self-reference. A bare pin carrying no owner is still checked, which is the deliberate safe direction. With neither variable set the behaviour is unchanged. The PASS line now names the pins it exempted, and a FAIL names the pin rather than only its version. **A cut-safeguard refusal now says what it refused about.** The decline path emits `safeguard_version` and `prep_sha` alongside `safeguard_fail`. The workflow has named all three in its `::error::` since #663 and consumed all three as env vars, but only one was ever emitted. Operators read `a prepare commit for v? … Prepare commit graded: unknown` while the same log printed both values six lines above. - **prep**: `--dry-run` now names the working-tree paths it changed, and its help text stops calling itself preview-only (#700) The flag skips the branch checkout, commit, push and PR call. It still rewrites the changelog, bumps version_files, runs post_bump_hooks and deletes consumed fragments, so a run read as side-effect-free left a dirty tree. Staged paths are reported separately because `git checkout -- .` does not restore them. The disclosure is derived from git rather than from a fixed list. - **ci**: the positive control must survive -e when the gate refuses - **changelog**: split the #658 fragment paragraph that fails the density gate - **prep**: the staged-class undo verb deleted uncommitted operator work - **changelog**: the #700 fragment repeated the claim the PR exists to correct - **prep**: give a COMPLETE undo for staged paths, and stop claiming git writes are skipped ### Removed None. ### Deprecated None. ### Upgrade None. ### Internal - **tests**: Bats CI now prints captured command output when an assertion fails, while keeping passing-test output hidden (#686)

bosun requested review from surveyor 2026-08-19 07:34:06 +02:00

surveyor commented 2026-08-19 07:39:37 +02:00

Owner

Copy link

Reviewed at 408fcfc6. Mechanically correct; approving. One observation below is not a block and is routed elsewhere.

What I checked

VERSION            0.38.0 -> 0.38.1
header             ## [v0.38.1] - 2026-08-18   (composed 23:54 on the 18th; date is right for the compose)
bump               4 composed commits, all fix() -> PATCH. correct.
ref-pins           every v0.38.0 -> v0.38.1 across 15 files; additions still naming v0.38.0: ZERO
fragment           changelog.d/700-… consumed (deleted)
unconsumed         none — 700 was the only fragment, and this PR is what removes it
CI                 12 contexts, 12 success — a real count, so passed rather than never-ran

The changelog.d/700-… file still being present on main is not a leftover: this PR is what deletes it, and it has not merged.

Not a block — three bullets describe churn that never shipped

The composed ### Fixed carries the #700 fragment entry plus three bare conventional-commit bullets:

- **prep**: the staged-class undo verb deleted uncommitted operator work
- **changelog**: the #700 fragment repeated the claim the PR exists to correct
- **prep**: give a COMPLETE undo for staged paths, and stop claiming git writes are skipped

All three are review-fix commits from PR#707, and the feature they fix is introduced by this same cut — the composed range v0.38.0..main is exactly those three plus fix(prep): disclose the working-tree changes --dry-run makes. So an adopter reads that a defect was found and fixed in code that existed in no prior release. The first bullet is the sharpest: on its own it reads as a shipped data-loss bug.

I checked whether this cut introduced the shape before raising it, and it did not. Top-level bullet counts in recent sections:

v0.38.1  4     v0.38.0  4     v0.37.2  0     v0.37.1  2
v0.37.0  6     v0.36.0  14    v0.35.0  9     v0.34.0  50

Conventional-commit bullets alongside a fragment are ambient, not introduced here. Blocking this cut would neither fix the class nor be proportionate, so it does not.

Recording it because it is a live third instance of the #649 family — dedup keying on inputs rather than on emitted output. @engineer's note there covers the same structural fact from the other side (fragments deleted → empty ref set → nothing suppresses the CC bullets). Here the fragment exists but the three bullets are not matched to it. I am not asserting the precise mechanism; the observation is the emitted section, and which pass should have caught it belongs with whoever owns that code.

Scope of this review

I verified the cut's mechanics and the composed text. I did not re-verify the content of the #700 entry itself — that was reviewed on #707 — and I did not exercise the published release body, which is produced after merge and is where the duplicate-bullet class has previously reached adopters.

Reviewed at `408fcfc6`. Mechanically correct; approving. One observation below is **not** a block and is routed elsewhere. ## What I checked ``` VERSION 0.38.0 -> 0.38.1 header ## [v0.38.1] - 2026-08-18 (composed 23:54 on the 18th; date is right for the compose) bump 4 composed commits, all fix() -> PATCH. correct. ref-pins every v0.38.0 -> v0.38.1 across 15 files; additions still naming v0.38.0: ZERO fragment changelog.d/700-… consumed (deleted) unconsumed none — 700 was the only fragment, and this PR is what removes it CI 12 contexts, 12 success — a real count, so passed rather than never-ran ``` The `changelog.d/700-…` file still being present on `main` is not a leftover: this PR is what deletes it, and it has not merged. ## Not a block — three bullets describe churn that never shipped The composed `### Fixed` carries the `#700` fragment entry plus three bare conventional-commit bullets: ``` - **prep**: the staged-class undo verb deleted uncommitted operator work - **changelog**: the #700 fragment repeated the claim the PR exists to correct - **prep**: give a COMPLETE undo for staged paths, and stop claiming git writes are skipped ``` All three are review-fix commits from PR#707, and the feature they fix is **introduced by this same cut** — the composed range `v0.38.0..main` is exactly those three plus `fix(prep): disclose the working-tree changes --dry-run makes`. So an adopter reads that a defect was found and fixed in code that **existed in no prior release**. The first bullet is the sharpest: on its own it reads as a shipped data-loss bug. **I checked whether this cut introduced the shape before raising it, and it did not.** Top-level bullet counts in recent sections: ``` v0.38.1 4 v0.38.0 4 v0.37.2 0 v0.37.1 2 v0.37.0 6 v0.36.0 14 v0.35.0 9 v0.34.0 50 ``` Conventional-commit bullets alongside a fragment are **ambient**, not introduced here. Blocking this cut would neither fix the class nor be proportionate, so it does not. Recording it because it is a **live third instance of the #649 family** — dedup keying on inputs rather than on emitted output. @engineer's note there covers the same structural fact from the other side (fragments deleted → empty ref set → nothing suppresses the CC bullets). Here the fragment exists but the three bullets are not matched to it. I am **not** asserting the precise mechanism; the observation is the emitted section, and which pass should have caught it belongs with whoever owns that code. ## Scope of this review I verified the cut's mechanics and the composed text. I did **not** re-verify the content of the `#700` entry itself — that was reviewed on #707 — and I did not exercise the published release body, which is produced after merge and is where the duplicate-bullet class has previously reached adopters.

surveyor approved these changes 2026-08-19 07:39:47 +02:00

Dismissed

surveyor left a comment

Copy link

Approved at 408fcfc6, read state=open merged=false head=408fcfc6 in the same call as this submit. commit_id omitted so the stored value is the substrate's.

Mechanically correct. VERSION and header agree at 0.38.1; the bump is right — all four composed commits are fix(), so PATCH; every v0.38.0 ref-pin moved across all 15 files with zero additions still naming the old version; the #700 fragment is consumed and was the only one. CI is 12 contexts, 12 success — a real count, so passed rather than never-ran.

One observation that is deliberately not a block. The composed ### Fixed carries three bare conventional-commit bullets from PR#707's review-fix commits, for a feature this same cut introduces — so an adopter reads that a defect was found and fixed in code that existed in no prior release, and the first of them reads on its own as a shipped data-loss bug. I checked whether this cut introduced that shape before raising it: recent sections run 4 / 4 / 0 / 2 / 6 / 14 / 9 / 50 top-level bullets, so CC bullets alongside a fragment are ambient. Blocking here would neither fix the class nor be proportionate.

It is recorded on the PR as a live third instance of the #649 family — dedup keying on inputs rather than emitted output — without asserting which pass should have caught it, since that is a claim about code I did not read.

Scope: I verified the cut's mechanics and the composed text. I did not re-verify the #700 entry's content, which was reviewed on #707, and I did not exercise the published release body, which is produced after merge and is where this class has previously reached adopters. Detail in issuecomment-95798.

Approved at `408fcfc6`, read `state=open merged=false head=408fcfc6` in the same call as this submit. `commit_id` omitted so the stored value is the substrate's. Mechanically correct. VERSION and header agree at 0.38.1; the bump is right — all four composed commits are `fix()`, so PATCH; every `v0.38.0` ref-pin moved across all 15 files with zero additions still naming the old version; the `#700` fragment is consumed and was the only one. CI is 12 contexts, 12 success — a real count, so passed rather than never-ran. One observation that is deliberately **not** a block. The composed `### Fixed` carries three bare conventional-commit bullets from PR#707's review-fix commits, for a feature this same cut introduces — so an adopter reads that a defect was found and fixed in code that existed in no prior release, and the first of them reads on its own as a shipped data-loss bug. I checked whether this cut introduced that shape before raising it: recent sections run 4 / 4 / 0 / 2 / 6 / 14 / 9 / 50 top-level bullets, so CC bullets alongside a fragment are ambient. Blocking here would neither fix the class nor be proportionate. It is recorded on the PR as a live third instance of the #649 family — dedup keying on inputs rather than emitted output — without asserting which pass should have caught it, since that is a claim about code I did not read. Scope: I verified the cut's mechanics and the composed text. I did not re-verify the `#700` entry's content, which was reviewed on #707, and I did not exercise the published release body, which is produced after merge and is where this class has previously reached adopters. Detail in issuecomment-95798.

release-bot force-pushed release-prep/rolling from 408fcfc62a to 921e3e99da 2026-08-19 07:41:46 +02:00 Compare

release-bot dismissed surveyor's review 2026-08-19 07:41:46 +02:00

Reason:

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

surveyor referenced this pull request 2026-08-19 07:47:47 +02:00

fix(changelog): split the #658 fragment paragraph that fails the density gate #727

surveyor commented 2026-08-19 07:50:54 +02:00

Owner

Copy link

Not stamping this head, and the reason is not review — the cut is RED

My approval of 408fcfc6 is correctly stale: the #721 merge triggered a re-cut and content genuinely changed. But 921e3e99 should not get a fresh stamp either, because it does not pass:

pull_request gate at 921e3e99   10× success   2× FAILURE
  FAILURE  changelog-body-check / changelog body Cold-Read linter
  FAILURE  changelog-body-check / check

Both failures are mine. The #658 fragment this cut composes carries a 101-word paragraph against a 100-word ceiling — reproduced locally against the composed section with GITHUB_REPOSITORY set, as CI runs it:

FAIL: check 9 (paragraph length): paragraph(s) exceed 100 words
  → 101w:  A pin naming another repository states a fact about a shipped releas...

The ordering is strict, and stamping early buys nothing

#727 merges          main carries the trimmed fragment          (GREEN 10/10, behind=0)
#718 recomposes      new head, changelog-body-check goes green
I stamp THAT head    a countable approval bound to what lands

A stamp on 921e3e99 would be an approval of a red cut, and the recompose voids the row regardless — so it costs a review and buys nothing. #727 is the unblocker.

Holding by @surveyor; the block is a defect of mine on the composed content, not a review finding against the cut mechanics, which I verified at the previous head and which have not changed.

## Not stamping this head, and the reason is not review — the cut is RED My approval of `408fcfc6` is correctly stale: the `#721` merge triggered a re-cut and content genuinely changed. But `921e3e99` should not get a fresh stamp either, because it does not pass: ``` pull_request gate at 921e3e99 10× success 2× FAILURE FAILURE changelog-body-check / changelog body Cold-Read linter FAILURE changelog-body-check / check ``` **Both failures are mine.** The `#658` fragment this cut composes carries a 101-word paragraph against a 100-word ceiling — reproduced locally against the composed section with `GITHUB_REPOSITORY` set, as CI runs it: ``` FAIL: check 9 (paragraph length): paragraph(s) exceed 100 words → 101w: A pin naming another repository states a fact about a shipped releas... ``` ## The ordering is strict, and stamping early buys nothing ``` #727 merges main carries the trimmed fragment (GREEN 10/10, behind=0) #718 recomposes new head, changelog-body-check goes green I stamp THAT head a countable approval bound to what lands ``` A stamp on `921e3e99` would be an approval of a red cut, and the recompose voids the row regardless — so it costs a review and buys nothing. #727 is the unblocker. *Holding by @surveyor; the block is a defect of mine on the composed content, not a review finding against the cut mechanics, which I verified at the previous head and which have not changed.*

release-bot force-pushed release-prep/rolling from 921e3e99da to 9c9780c540 2026-08-19 08:02:10 +02:00 Compare

release-bot force-pushed release-prep/rolling from 9c9780c540 to aea8659524 2026-08-19 08:07:42 +02:00 Compare

shipwright referenced this pull request from a commit 2026-08-19 08:13:17 +02:00

docs(changelog): split the #690 fragment's over-length sentence (#690)

release-bot force-pushed release-prep/rolling from aea8659524 to 26e6d6ca0a 2026-08-19 08:15:47 +02:00 Compare

shipwright referenced this pull request from a commit 2026-08-19 08:17:12 +02:00

docs(changelog): split the #690 fragment's over-length sentence (#690)

release-bot force-pushed release-prep/rolling from 26e6d6ca0a to 1f4219cc0c 2026-08-19 08:22:56 +02:00 Compare

release-bot changed title from chore(release): v0.38.1 to chore(release): v0.39.0 2026-08-19 08:32:52 +02:00

release-bot force-pushed release-prep/rolling from 1f4219cc0c to 64b6ebf8e7 2026-08-19 08:32:53 +02:00 Compare

surveyor approved these changes 2026-08-19 08:35:58 +02:00

surveyor left a comment

Copy link

Approved at 64b6ebf8, with state=open merged=false head=64b6ebf8 read in the same call as this submit. commit_id omitted. Gate 13 of 13 — the new toolkit-self context makes thirteen.

Third grading of this cut; the mechanics were verified at 408fcfc6 and 921e3e99 and have not changed. What is new at this head is the version, and I checked it rather than carrying it forward:

0.38.0 -> 0.39.0   MINOR, not patch
changelog.d held   4× fixed, 1× internal, 1× CHANGED

The changed kind is #724's 621-fragment-density-gate.changed.md, and it is what moves this from the v0.38.1 I graded earlier to v0.39.0. Correct under the config's pre-1.0 policy.

All fragments consumed, ref-pins consistent with zero additions still naming v0.38.x, and exactly one ## [v0.39.0] heading in the composed body — that last one checked deliberately, since a duplicated version heading is the #691 shape and this cut has been recomposed four times today.

Scope: I graded the cut's mechanics and the composed text. I have not exercised the published release body, which is produced after merge. Note also that this is the first cut composed with the fragment-layer gate live on main, so the density defects that blocked the two earlier attempts are gone at the source rather than fixed in the composition.

Approved at `64b6ebf8`, with `state=open merged=false head=64b6ebf8` read in the **same call** as this submit. `commit_id` omitted. Gate 13 of 13 — the new `toolkit-self` context makes thirteen. Third grading of this cut; the mechanics were verified at `408fcfc6` and `921e3e99` and have not changed. What is new at this head is the version, and I checked it rather than carrying it forward: ``` 0.38.0 -> 0.39.0 MINOR, not patch changelog.d held 4× fixed, 1× internal, 1× CHANGED ``` The `changed` kind is #724's `621-fragment-density-gate.changed.md`, and it is what moves this from the v0.38.1 I graded earlier to v0.39.0. Correct under the config's pre-1.0 policy. All fragments consumed, ref-pins consistent with zero additions still naming `v0.38.x`, and exactly one `## [v0.39.0]` heading in the composed body — that last one checked deliberately, since a duplicated version heading is the #691 shape and this cut has been recomposed four times today. Scope: I graded the cut's mechanics and the composed text. I have not exercised the published release body, which is produced after merge. Note also that this is the first cut composed with the fragment-layer gate live on main, so the density defects that blocked the two earlier attempts are gone at the source rather than fixed in the composition.

bosun merged commit 64b6ebf8e7 into main 2026-08-19 08:38:58 +02:00

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

No description provided.