From 977c3ce2530547b8b1a33c16aa5f79fefb0d9433 Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 7 Sep 2026 10:56:32 +0000 Subject: [PATCH 1/2] chore: bump the minor, not the major, for a pre-1.0 breaking change CLAUDE.md has always said `feat!:` bumps the minor before 1.0, but the config never set `bump-minor-pre-major`, so release-please read a pre-1.0 breaking change as the 1.0.0 promotion instead. #181 was the first commit to test that gap and it proposed 1.0.0 off a removed badge, which had to be walked back by hand in #182. Sets the option so the documented rule is the actual one, and writes down the two squash-merge consequences that made the mistake unrecoverable in-band: a `!` in a PR title is the whole decision (there is no body left to carry a `BREAKING CHANGE:` footer), and `Release-As:` cannot work here for exactly the same reason, so pinning a version means editing the release PR in six places. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Gtr5DLgddkeyaC3cHUQqgb --- CLAUDE.md | 6 +++++- release-please-config.json | 1 + 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/CLAUDE.md b/CLAUDE.md index 73605b25..83d5befb 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -46,7 +46,11 @@ All repos live under the `wavekat` GitHub org. SSH access uses the `github.com-w This repo uses **release-please**. Since GitHub squash-merges use the PR title as the commit message, the PR title must have a conventional prefix or release-please will silently ignore the commit. - `feat:` / `fix:` → patch bump (pre-1.0, per `bump-patch-for-minor-pre-major`) -- `feat!:` / `fix!:` → minor bump (pre-1.0) +- `feat!:` / `fix!:` → minor bump (pre-1.0, per `bump-minor-pre-major`) + +**The squash also drops the commit body, so a `!` in the title is the whole decision** — there is no `BREAKING CHANGE:` footer to reconsider later, and nothing else in the PR moderates it. Reach for `!` only for a change that genuinely breaks something; a copy tweak, a removed badge or a restyled control is a `feat:`. This is not theoretical: #181 removed a download-row badge, was titled `feat!:`, and — with `bump-minor-pre-major` then unset — release-please proposed **1.0.0**, which had to be walked back by hand in #182. + +For the same reason, **`Release-As: x.y.z` does not work here.** It is read from a commit body, and the squash discards it. To pin a version, edit the release PR instead: its title, its body (release-please parses the released version out of the body on merge, so the tag follows it), `CHANGELOG.md`, `.release-please-manifest.json`, `package.json` and `package-lock.json` — all six, or the tag and the manifest disagree. ## Tech decisions diff --git a/release-please-config.json b/release-please-config.json index f30bd5ff..e900e773 100644 --- a/release-please-config.json +++ b/release-please-config.json @@ -2,6 +2,7 @@ "$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json", "release-type": "node", "bump-patch-for-minor-pre-major": true, + "bump-minor-pre-major": true, "packages": { ".": {} } From 0ebfe76c133ac9b31ac5bd4d1ddd6c47455e5cda Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 7 Sep 2026 11:03:44 +0000 Subject: [PATCH 2/2] chore: say precisely what the squash does to a commit body MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The first draft claimed the squash always drops the body. #181 did land as its title alone, but #182 kept its body — so the honest rule is that what survives beyond the title varies with how the PR is merged, which is itself the reason a version override must not live there. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Gtr5DLgddkeyaC3cHUQqgb --- CLAUDE.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index 83d5befb..8bdb2327 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -48,9 +48,9 @@ This repo uses **release-please**. Since GitHub squash-merges use the PR title a - `feat:` / `fix:` → patch bump (pre-1.0, per `bump-patch-for-minor-pre-major`) - `feat!:` / `fix!:` → minor bump (pre-1.0, per `bump-minor-pre-major`) -**The squash also drops the commit body, so a `!` in the title is the whole decision** — there is no `BREAKING CHANGE:` footer to reconsider later, and nothing else in the PR moderates it. Reach for `!` only for a change that genuinely breaks something; a copy tweak, a removed badge or a restyled control is a `feat:`. This is not theoretical: #181 removed a download-row badge, was titled `feat!:`, and — with `bump-minor-pre-major` then unset — release-please proposed **1.0.0**, which had to be walked back by hand in #182. +**A `!` in the PR title is the whole decision** — there is no `BREAKING CHANGE:` footer to reconsider later, and nothing else in the PR moderates it. Reach for `!` only for a change that genuinely breaks something; a copy tweak, a removed badge or a restyled control is a `feat:`. This is not theoretical: #181 removed a download-row badge, was titled `feat!:`, and — with `bump-minor-pre-major` then unset — release-please proposed **1.0.0**, which had to be walked back by hand in #182. -For the same reason, **`Release-As: x.y.z` does not work here.** It is read from a commit body, and the squash discards it. To pin a version, edit the release PR instead: its title, its body (release-please parses the released version out of the body on merge, so the tag follows it), `CHANGELOG.md`, `.release-please-manifest.json`, `package.json` and `package-lock.json` — all six, or the tag and the manifest disagree. +For the same reason, **don't reach for `Release-As: x.y.z` to pin a version.** It is read from a commit message on `main`, and the squash replaces every commit message on the branch with one composed from the PR — so a footer written in a branch commit never arrives. What the squash keeps beyond the title varies with how the PR is merged (#181 landed as its title alone, body dropped; #182 kept its body), which makes it exactly the wrong place for a version override to live. Pin the version by editing the release PR instead — its title, its body (release-please parses the released version out of the body on merge, so the tag follows it), `CHANGELOG.md`, `.release-please-manifest.json`, `package.json` and `package-lock.json`. All six, or the tag and the manifest disagree. ## Tech decisions