Allow changelog-sections to override a commit type's SemVer bump

Author: bogaertgCreated Sep 17, 2026Updated Sep 18, 2026
Labelstype: feature requestpriority: p3

Is your feature request related to a problem? Please describe.

Under Conventional Commits, only feat/fix/a breaking change are meant to bump a version; other types (ci, chore, docs, refactor, ...) are conventionally non-releasing. DefaultVersioningStrategy.determineReleaseType doesn't reflect that: any commit type that isn't feat/breaking falls through to an unconditional PatchVersionUpdate(). Combined with changelog-sections, this produces a confusing gotcha: a type must be listed (and not hidden) to render in the changelog, but as soon as it is, changelogEmpty() (strategies/base.ts) sees non-empty output and lets the release PR through -- so a lone ci: commit on main opens/updates a release PR the moment its type gains a visible changelog-sections entry. hidden: true avoids the release, but then the commit never renders either -- there's no way to have a type both visible in the changelog and non-releasing. See also #2638, which reports the same surprise without a resolution.

Describe the solution you'd like

Add an optional bump field to each changelog-sections entry: "none" | "minor" | "major" | "breaking". none excludes that commit from ever contributing a bump (still overridden by an explicit breaking change or Release-As footer on the same commit); minor/major force that bump as if the commit were feat/breaking; breaking is an alias for major. Unset (the default, for every existing config) leaves classification exactly as it is today -- fully backward compatible.

This decouples "does this type render in the changelog" (hidden) from "does this type affect the version" (bump), so e.g. {"type": "ci", "section": "CI/CD", "bump": "none"} shows CI commits in the changelog of a release that already happened for another reason, without a lone ci: commit ever opening one itself.

Describe alternatives you've considered

  • Gating on commit type further upstream, outside release-please (in the calling CI), which is what we ended up doing as a workaround -- but it can only omit the type entirely, not the "visible but non-releasing" combination.
  • hidden: true -- prevents the release, but also removes the entry from the changelog entirely, which isn't the same thing.

Happy to open a PR implementing this (backward-compatible, full test coverage, no changes to any existing test's expected output) if the direction looks acceptable.

Source: googleapis/release-please