[GH-ISSUE #76] Confusing wording on BREAKING CHANGE #4094

New Issue

GiteaMirror · 2026-04-27T15:18:48-05:00

GiteaMirror commented

2026-04-27 15:18:48 -05:00

Originally created by @skinny85 on GitHub (Aug 15, 2018).
Original GitHub issue: https://github.com/conventional-commits/conventionalcommits.org/issues/76

The "Breaking Change" bullet point nr 3 states:

BREAKING CHANGE: a commit that has the text BREAKING CHANGE: at the beginning of its optional body or footer section introduces a breaking API change (correlating with MAJOR in semantic versioning). A breaking change can be part of commits of any type.

Then, the next bullet point "Others" nr 4 states:

Others: commit types other than fix: and feat: are allowed, for example (...) chore:, docs:, style:, refactor:, perf:, test:, and others. (...) Notice these types are not mandated by the conventional commits specification, and have no implicit effect in semantic versioning (unless they include a BREAKING CHANGE, which is NOT recommended).

I feel like these two points are contradicting each other.

Originally created by @skinny85 on GitHub (Aug 15, 2018). Original GitHub issue: https://github.com/conventional-commits/conventionalcommits.org/issues/76 The "Breaking Change" bullet point nr 3 states: > 3. BREAKING CHANGE: a commit that has the text BREAKING CHANGE: at the beginning of its optional body or footer section introduces a breaking API change (correlating with MAJOR in semantic versioning). **A breaking change can be part of commits of any type**. Then, the next bullet point "Others" nr 4 states: > 4. Others: commit types other than fix: and feat: are allowed, for example (...) chore:, docs:, style:, refactor:, perf:, test:, and others. (...) Notice these types are not mandated by the conventional commits specification, and have no implicit effect in semantic versioning (**unless they include a BREAKING CHANGE, which is NOT recommended**). I feel like these two points are contradicting each other.

GiteaMirror added the suggestion label 2026-04-27 15:18:48 -05:00

GiteaMirror closed this issue

2026-04-27 15:18:49 -05:00

GiteaMirror commented

2026-04-27 15:18:50 -05:00

@damianopetrungaro commented on GitHub (Aug 15, 2018):

@skinny85 thank you for opening the issue!

If you think they are contradicting each other it means we can find a way to put it in a better way.

I think the main point that may be confusing is that creating your own commit type (commit types other than fix: and feat: are allowed) you MAY use BREAKING CHANGE in any commit message.

If you want to open a PR to put this in a different way you are welcome.
Let's see also whay @hbetts @zeke @bcoe think about it.

btw we are discussing about BREAKING CHANGE: itself on #43, feel free to join the discussion.

@damianopetrungaro commented on GitHub (Aug 15, 2018): @skinny85 thank you for opening the issue! If you think they are contradicting each other it means we can find a way to put it in a better way. I think the main point that may be confusing is that creating your own commit type (`commit types other than fix: and feat: are allowed`) you _MAY_ use `BREAKING CHANGE` in any commit message. If you want to open a PR to put this in a different way you are welcome. Let's see also whay @hbetts @zeke @bcoe think about it. ___ btw we are discussing about `BREAKING CHANGE:` itself on #43, feel free to join the discussion.

GiteaMirror commented

2026-04-27 15:18:50 -05:00

@hutson commented on GitHub (Aug 15, 2018):

My personal preference would be to remove the reference to BREAKING CHANGE from item (4).

I think the bolded line from item (3) is sufficient.

@hutson commented on GitHub (Aug 15, 2018): My personal preference would be to remove the reference to `BREAKING CHANGE` from item (4). I think the bolded line from item (3) is sufficient.

GiteaMirror commented

2026-04-27 15:18:51 -05:00

@damianopetrungaro commented on GitHub (Aug 15, 2018):

@hbetts but in this way and have no implicit effect in semantic versioning is "wrong" too.

@damianopetrungaro commented on GitHub (Aug 15, 2018): @hbetts but in this way `and have no implicit effect in semantic versioning` is "wrong" too.

GiteaMirror commented

2026-04-27 15:18:52 -05:00

@skinny85 commented on GitHub (Aug 15, 2018):

I would just remove , which is NOT recommended from bullet nr 4 - that's the source of the contradiction for me.

@skinny85 commented on GitHub (Aug 15, 2018): I would just remove `, which is NOT recommended` from bullet nr 4 - that's the source of the contradiction for me.

GiteaMirror commented

2026-04-27 15:18:53 -05:00

@hutson commented on GitHub (Aug 19, 2018):

@damianopetrungaro thank you for pointing out that line.

In that case I like @skinny85's suggestion.

Can we go with that?

@hutson commented on GitHub (Aug 19, 2018): @damianopetrungaro thank you for pointing out that line. In that case I like @skinny85's suggestion. Can we go with that?

GiteaMirror commented

2026-04-27 15:18:53 -05:00

@damianopetrungaro commented on GitHub (Aug 20, 2018):

+1 for me.
@skinny85 do you have time to work on it?

@damianopetrungaro commented on GitHub (Aug 20, 2018): +1 for me. @skinny85 do you have time to work on it?

GiteaMirror commented

2026-04-27 15:18:54 -05:00

@skinny85 commented on GitHub (Aug 20, 2018):

@damianopetrungaro sure, I'll try to do a quick PR today or tomorrow.

@skinny85 commented on GitHub (Aug 20, 2018): @damianopetrungaro sure, I'll try to do a quick PR today or tomorrow.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#4094