chore: enable bump-minor-pre-major for pre-1.0 releases#79
Merged
StefanSteiner merged 1 commit intoMay 29, 2026
Merged
Conversation
Configures release-please to bump 0.x.y → 0.(x+1).0 on a BREAKING CHANGE: footer instead of bumping straight to 1.0.0. The default release-please behavior for any 0.x.y release-type:simple package is that BREAKING CHANGE triggers a 1.0.0 bump; bump-minor-pre-major:true overrides that to "BREAKING CHANGE while < 1.0.0 only bumps minor". Why now: PR tableau#77 (the v0.3.0 rollup) carries a BREAKING CHANGE: footer. release-please opened release PR tableau#78 proposing 1.0.0. We closed tableau#78 without merging — the manifest is still 0.2.3, no tag was cut. With this config change, the next release-please run will recompute against main and propose 0.3.0 instead of 1.0.0. Schema verification: bump-minor-pre-major is a documented field on the release-please config schema at both the top level (acts as default for all packages) and the per-package level. Verified against https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json and the implementation in release-please src/manifest.ts:1746-1747 which reads pathConfig.bumpMinorPreMajor ?? defaultConfig.bumpMinorPreMajor. Setting both explicitly for defense-in-depth. This config is evaluated against current commits at run time, so it applies retroactively to the BREAKING CHANGE: footer already on main. No need to amend the rollup commit or cherry-pick history. Note: the closed PR tableau#78 still has the autorelease: pending label. That label only matters on OPEN PRs; release-please's matcher (findOpenReleasePullRequests) ignores closed ones unless they carry autorelease: snooze. PR tableau#78 is therefore invisible to the next run, which will open a fresh release PR with the corrected 0.3.0 proposal.
This was referenced May 29, 2026
StefanSteiner
added a commit
that referenced
this pull request
May 29, 2026
…stays the gate (#87) Configures release-please to NOT create the GitHub Release / git tag when the "chore: release main" PR merges. release-please continues to open release PRs (CHANGELOG, version bumps, manifest updates) — only the auto-tagging step is disabled. The maintainer creates the tag manually via `gh release create`, which fires release.yml → crates.io publish. Why: crates.io and npm are immutable. Once cargo publish succeeds, the version exists forever; cargo yank only marks it "don't pick by default" without freeing the version slot. The manual tag step is the only maintainer-controlled checkpoint between merging the release PR and permanently publishing the version. We discovered this property inadvertently during the v0.3.0 release: release-please failed to auto-tag (upstream googleapis/release-please#1946), forcing a manual gh release create + label-edit recovery. The recovery worked cleanly and the human checkpoint turned out to be valuable — better to codify it than depend on an upstream bug staying broken. Schema verification: skip-github-release is documented at both the top-level and per-package level in https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json (found at $.properties.skip-github-release and at $.definitions.ReleaserConfigOptions.properties.skip-github-release). Setting both for defense-in-depth and to make intent explicit, matching the bump-minor-pre-major pattern from #79. Cost: every release becomes manual, including patch releases. The tag-creation procedure is documented in #83 (filed for follow-up docs work in GITHUB_OPERATIONS.md). Net: trades one-time-per-release manual work for permanent prevention of accidentally shipping an incorrect version to immutable registries.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Configures release-please to bump 0.x.y → 0.(x+1).0 on a
BREAKING CHANGE:footer instead of jumping straight to 1.0.0. Adds"bump-minor-pre-major": truetorelease-please-config.jsonat both the top level (default for all packages) and the per-package level (defense-in-depth).Why now — recovery from PR #78
PR #77 (the v0.3.0 rollup) carried a
BREAKING CHANGE:footer. After it merged, release-please opened PR #78 titledchore: release mainproposing 1.0.0 — release-please's default behavior on a 0.x.y release-type:simple package is thatBREAKING CHANGE:triggers a 1.0.0 bump.That's not what we wanted. We wanted 0.3.0 (the API is intentionally still pre-1.0). PR #78 was closed without merging.
State right now (verified):
.release-please-manifest.jsonis still{".":"0.2.3"}(no tag cut, manifest never bumped) ✅v0.3.0orv1.0.0git tag exists onmain✅autorelease: pendinglabel still attachedv0.2.3This config change applies retroactively. release-please evaluates
bump-minor-pre-majoragainst current commits at run time (verified in src/manifest.ts:1746-1747), so theBREAKING CHANGE:footer already onmainwill produce a 0.3.0 proposal on the next run.Schema verification
Field exists at both levels in the release-please config schema:
properties.bump-minor-pre-major(acts as default)definitions.ReleaserConfigOptions.properties.bump-minor-pre-major(overrides default)Source impl at line 1746 reads
pathConfig.bumpMinorPreMajor ?? defaultConfig.bumpMinorPreMajor, so per-package wins; setting both is harmless and makes intent explicit.What happens after merge
autorelease: snooze→ ignored byfindOpenReleasePullRequestsmatcher.0.2.3.BREAKING CHANGE:footer on PR feat: stabilize v0.3.0 public API bundle #77's commit.bump-minor-pre-major: true→ bump rule is "minor on BREAKING < 1.0.0".chore: release maintitle.CHANGELOG.mddraft on that PR — should aggregate chore(api): flatten Error enum and add ergonomic constructors workspace-wide (#70) #71, chore(api): deprecate raw transaction trio; migrate MCP async paths to RAII (#69) #73, chore(api): modernize FromRow with #[derive] + RowAccessor (#61, #62) #74, chore(api): v0.3.0 follow-ups (A: typed I/O sources, B: InvalidOperation, C: structured SQLSTATE) #76 contributions (allchore(api):commits get reclassified under the major-bump section because of the BREAKING CHANGE footer; the bump itself is constrained to minor by this flag).v0.3.0, firesrelease.yml(crates.io publish — now withhyperdb-api-derivecorrectly in the publish list per feat: stabilize v0.3.0 public API bundle #77 commit 2), andnpm-build-publish.yml.Why not other paths
Release-As: 0.3.0empty commit): one-shot override; leaves the misconfiguration in place. A future 0.x BREAKING CHANGE would re-trigger the same 1.0.0 trap. Path A fixes the underlying config.0.3.0): would tell release-please that 0.3.0 is already released. Next release PR would compute from there as if v0.3.0 had been tagged. Silently drops the v0.3.0 release entirely. Avoid.autorelease: snoozeon PR chore: release main #78: snooze prevents re-proposal of the exact same version; release-please would still want 1.0.0 next time. Snoozing without changing the bump rule is "wait until something changes" — and this PR is what makes something change.Test plan
python3 -m json.toolpasses)chore: release mainPR proposing 0.3.0 (not 1.0.0)CHANGELOG.md— must list Flatten Error type to canonical M-ERRORS shape (drop Client wrapper, Box<dyn> source, Option<ErrorKind>) #70, Remove the &self begin_transaction/commit/rollback trio (RAII Transaction is the only safe path) #69, Add #[derive(FromRow)] and named-column access for cleaner struct mapping #61, FromRow redesign (breaking): typed RowAccessor, structured errors, enforced NULL semantics #62, chore(api): v0.3.0 follow-ups (A: typed I/O sources, B: InvalidOperation, C: structured SQLSTATE) #76 contributionsIf the new release PR still proposes 1.0.0 after this merges, fall back to Path B:
git commit --allow-empty -m "chore: release 0.3.0\n\nRelease-As: 0.3.0".Closes the recovery flow opened by closing PR #78.