Skip to content

chore(release): bump minor rather than major for pre-1.0 breaking changes - #53

Merged
njbrake merged 1 commit into
mainfrom
fix/bump-minor-pre-major
Aug 6, 2026
Merged

njbrake merged 1 commit into
mainfrom
fix/bump-minor-pre-major

Conversation

@njbrake

@njbrake njbrake commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

Note: this PR was drafted by Claude via back-and-forth with @njbrake. The reasoning and decisions are his; the prose is Claude's.

Stops release-please proposing 1.0.0. With bump-minor-pre-major, a breaking change under 1.0.0 bumps the minor instead of the major, so the pending release PR (#51) should recompute from 1.0.0 to 0.3.0.

The 1.0.0 came from fix(control-plane)!: map generated errors to typed OtariError (#47), the only ! commit since the 0.2.0 tag. Publishing 1.0.0 would signal API stability we are not committing to yet, and the Release workflow publishes to crates.io in the same run as the release PR merge, where the only undo is a yank.

Deliberately not setting bump-patch-for-minor-pre-major: feat: should keep bumping the minor, which is how 0.2.0 was cut.

Verified bump-minor-pre-major against the release-please config schema (ReleaserConfigOptions, "Breaking changes only bump semver minor if version < 1.0.0"), and the full file validates.

The same setting is missing from otari-sdk-go, otari-sdk-python, and otari-sdk-ts, which are all pre-1.0 with the same behaviour latent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant