conventionalcommits.org
conventionalcommits.org copied to clipboard
conventional-commits
breaking change should bump minor if version pre-1.0
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.
featcausesMINORchange etc.)
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
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?
When it is stable you tag it as 1.0.0 usually
On Sun, Jun 30, 2019, 14:13 Jason Kuhrt [email protected] 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 .
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.