[GH-ISSUE #165] breaking change should bump minor if version pre-1.0 #2054

New Issue

GiteaMirror · 2026-04-16T01:08:55-05:00

GiteaMirror commented

2026-04-16 01:08:55 -05:00

Originally created by @jasonkuhrt on GitHub (Jun 30, 2019).
Original GitHub issue: https://github.com/conventional-commits/conventionalcommits.org/issues/165

In accordance with https://semver.org/#spec-item-4

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

I don't think it makes sense that conventional commits assume BREAKING CHANGE always means bumping the major. Some projects might be unstable for a while but still want to communicate breaking changes to their users in a changelog/git history etc.

I think the spec should be as follows:

When BREAKING CHANGE is present:

if package version is >= 1.x.x bump MAJOR
if package version is < 1.x.x NO EFFECT, proceed with other rules as normal (e.g. feat causes MINOR change etc.)

Originally created by @jasonkuhrt on GitHub (Jun 30, 2019). Original GitHub issue: https://github.com/conventional-commits/conventionalcommits.org/issues/165 In accordance with https://semver.org/#spec-item-4 > Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable. I don't think it makes sense that conventional commits assume BREAKING CHANGE always means bumping the major. Some projects might be unstable for a while but still want to communicate breaking changes to their users in a changelog/git history etc. I think the spec should be as follows: When BREAKING CHANGE is present: 1. if package version is >= 1.x.x bump MAJOR 2. if package version is < 1.x.x NO EFFECT, proceed with other rules as normal (e.g. `feat` causes `MINOR` change etc.)

GiteaMirror commented

2026-04-16 01:08:56 -05:00

@damianopetrungaro commented on GitHub (Jun 30, 2019):

We should specify that if it is a 0.x.x we may not bump it up.

If > 0.x.y then https://semver.org/#spec-item-8

@damianopetrungaro commented on GitHub (Jun 30, 2019): We should specify that if it is a 0.x.x we may not bump it up. If > 0.x.y then https://semver.org/#spec-item-8

GiteaMirror commented

2026-04-16 01:08:57 -05:00

@jasonkuhrt commented on GitHub (Jun 30, 2019):

we may not bump it up.

It should probably not be ambiguous so must not rather than may not.

But then, how does a user bump to 1.0.0?

@jasonkuhrt commented on GitHub (Jun 30, 2019): > we may not bump it up. It should probably not be ambiguous so `must not` rather than `may not`. But then, how does a user bump to 1.0.0?

GiteaMirror commented

2026-04-16 01:08:57 -05:00

@damianopetrungaro commented on GitHub (Jun 30, 2019):

When it is stable you tag it as 1.0.0 usually

On Sun, Jun 30, 2019, 14:13 Jason Kuhrt notifications@github.com wrote:

we may not bump it up.

It should probably not be ambiguous so must not rather than may not.

But then, how does a user bump to 1.0.0?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/conventional-commits/conventionalcommits.org/issues/165?email_source=notifications&email_token=ACEJFZY5PMRZBAJG6QJT6T3P5CPOJA5CNFSM4H4LT5GKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY4K6BQ#issuecomment-507031302,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACEJFZ7YPDPF7HVIS4VA4FTP5CPOJANCNFSM4H4LT5GA
.

@damianopetrungaro commented on GitHub (Jun 30, 2019): When it is stable you tag it as 1.0.0 usually On Sun, Jun 30, 2019, 14:13 Jason Kuhrt <notifications@github.com> wrote: > we may not bump it up. > > It should probably not be ambiguous so must not rather than may not. > > But then, how does a user bump to 1.0.0? > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <https://github.com/conventional-commits/conventionalcommits.org/issues/165?email_source=notifications&email_token=ACEJFZY5PMRZBAJG6QJT6T3P5CPOJA5CNFSM4H4LT5GKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY4K6BQ#issuecomment-507031302>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ACEJFZ7YPDPF7HVIS4VA4FTP5CPOJANCNFSM4H4LT5GA> > . >

GiteaMirror commented

2026-04-16 01:08:58 -05:00

@jasonkuhrt commented on GitHub (Jun 30, 2019):

Yes certainly, but I was referring to the ability for conventional commits to support a well known commit pattern that would facilitate machines performing the bump. But the ROI on automation around a singular event (to a project) is questionable.

@jasonkuhrt commented on GitHub (Jun 30, 2019): Yes certainly, but I was referring to the ability for conventional commits to support a well known commit pattern that would facilitate machines performing the bump. But the ROI on automation around a singular event (to a project) is questionable.

GiteaMirror commented

2026-04-16 01:08:58 -05:00

@damianopetrungaro commented on GitHub (Oct 10, 2019):

@jasonkuhrt wanna open a PR about this?
It sounds good to me :)

@damianopetrungaro commented on GitHub (Oct 10, 2019): @jasonkuhrt wanna open a PR about this? It sounds good to me :)

GiteaMirror commented

2026-04-16 01:08:59 -05:00

@jasonkuhrt commented on GitHub (Oct 11, 2019):

@damianopetrungaro Will do!

@jasonkuhrt commented on GitHub (Oct 11, 2019): @damianopetrungaro Will do!

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#2054