chore(release): cap auto-bumps at minor to avoid accidental majors#1608
chore(release): cap auto-bumps at minor to avoid accidental majors#1608MuncleUscles wants to merge 1 commit intomainfrom
Conversation
Add `{ breaking: true, release: "minor" }` as the first entry in
`releaseRules` so that commits carrying a BREAKING CHANGE footer or
`!:` marker produce a minor bump instead of a major one.
Background: `@semantic-release/commit-analyzer` ships with a built-in
default rule `{ breaking: true, release: "major" }`. That default is
consulted whenever the user-provided `releaseRules` don't cover a
commit. The existing user rules (`feat` → minor, `*` → patch) do
not match on the `breaking` flag, so a stray "BREAKING CHANGE:"
line in any commit body would immediately ship a major release — at
the current 0.117.x state, that means 0.117.x → 1.0.0 without any
intended stability declaration.
By explicitly matching `breaking: true` first, we keep the default
major-bump rule from being evaluated for those commits. Genuine
major releases still work via an explicit `semantic-release
--release major` override (or a deliberate config change).
Mirrors the equivalent fixes shipped in:
- genlayer-js (PR #159, release-it + whatBump)
- genlayer-cli (PR #295, release-it + whatBump)
User rules are evaluated before the defaults (per semantic-release's
commit-analyzer documentation); defaults only apply when no user rule
matches. Adding `breaking: true` at the top of `releaseRules`
therefore prevents the default `major` rule from firing for breaking
commits.
Effect:
- BREAKING CHANGE footer / `!:` marker → minor (was: major)
- feat: → minor (unchanged)
- everything else → patch (unchanged)
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 24 minutes and 7 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Summary
Add
{ breaking: true, release: "minor" }as the first entry inreleaseRulesso that commits with aBREAKING CHANGEfooter or!:marker produce a minor bump instead of a major one.Why
@semantic-release/commit-analyzerships with a built-in default rule{ breaking: true, release: "major" }. That default is consulted whenever the user-providedreleaseRulesdon't cover a commit. The existing user rules (feat → minor,* → patch) do not match on thebreakingflag, so a stray "BREAKING CHANGE:" line in any commit body would immediately ship a major release.At the current 0.117.x state, that means the next accidental breaking footer would jump the project to 1.0.0 — not as a deliberate stability declaration, but as a side effect of commit-message parsing.
genlayer-jshit exactly that trap yesterday (0.28.7 → 1.0.0 unintentionally); this PR prevents the same thing here.Mirrors the equivalent fixes in:
genlayer-js(PR 152 simulator frontend fixes and improvements #159,release-it+whatBump)genlayer-cli(PR Testing branch rules #295,release-it+whatBump)How it works
Per
@semantic-release/commit-analyzerdocs: user rules inreleaseRulesare evaluated first; the default release rules are only consulted when no user rule matches. By explicitly matchingbreaking: trueat the top of our rules, we keep the defaultmajorrule from firing for those commits.Effect
BREAKING CHANGEfooter /!:markerfeat:fix:,chore:,docs:, …)semantic-release --release majorTest plan
node -e 'require(\"./release.config.js\")'parses cleanBREAKING CHANGE:footer happens to land, it should produce a minor version, not a major.