From 74a8fb55f5706e1284cbae510660ae34131e7392 Mon Sep 17 00:00:00 2001 From: David Cozens Date: Wed, 22 Apr 2026 20:42:55 +0100 Subject: [PATCH] chore: pin release-please's first release to 0.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit #191 added bump-minor-pre-major: true, but that flag only affects releases *after* the first. The first-release path uses a separate computation that didn't pick up the flag, so release-please still proposed 1.0.0 because of the feat!: commit in history. initial-version is the purpose-built knob for this case: it forces the very first release out of manifest 0.0.0 to a specified version, skipping the normal major/minor/patch computation. 0.1.0 matches the version ladder: first labelled beta candidate once SD coverage and Windows reliable transport land. After this merges, PR #101's title should re-render from "release 1.0.0" to "release 0.1.0". bump-minor-pre-major keeps subsequent breaking changes capped at minor bumps (0.1.0 → 0.2.0, not → 1.0.0), in line with the 0.x-is-beta policy. --- release-please-config.json | 1 + 1 file changed, 1 insertion(+) diff --git a/release-please-config.json b/release-please-config.json index d86e1010..019891f6 100644 --- a/release-please-config.json +++ b/release-please-config.json @@ -2,6 +2,7 @@ "packages": { ".": { "release-type": "simple", + "initial-version": "0.1.0", "bump-minor-pre-major": true, "changelog-sections": [ { "type": "feat", "section": "Features" },