BREAKING CHANGE does not trigger major version bump about commit-analyzer HOT 13 CLOSED

[3:14:37 PM] [semantic-release] › ✔  Completed step "verifyConditions" of plugin "@semantic-release/github"
[3:14:38 PM] [semantic-release] › ℹ  Found git tag v1.1.0 associated with version 1.1.0
[3:14:38 PM] [semantic-release] › ℹ  Found 1 commits since last release
[3:14:38 PM] [semantic-release] › ℹ  Start step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[3:14:38 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: BREAKING CHANGE: Updated to RxJS 6, Bump Package Version
[3:14:38 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The commit should not trigger a release
[3:14:38 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analysis of 1 commits complete: no release
[3:14:38 PM] [semantic-release] › ✔  Completed step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[3:14:38 PM] [semantic-release] › ℹ  There are no relevant changes, so no new version is released.

I have same Issue, I added BREAKING CHANGE: with more text, even then It did not trigger a major version bump.

from commit-analyzer.

Could you provide a link to the commit that didn't trigger the major release? Or if not possible, the commit message?

For information, we are using conventional-changelog to parse commit messages. So it's a parsing problem, the fix might have to be done over there.

from commit-analyzer.

Job that did major bump: https://travis-ci.org/flipactual/dx/jobs/335409093
Job that did not major bump: https://travis-ci.org/flipactual/dx/jobs/335406095

Sorry if I opened the issue in the wrong place!

from commit-analyzer.

Per the Angular commit format:

Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then used for this.

So if you just write BREAKING CHANGE in the commit body without : or an explanation of the breaking it's not recognized as a breaking change commit.

One of the goal of mentioning a breaking change in a commit is to explain what the breaking change is, and to include it in the release note. It doesn't really make much sense to not add the explanation. That said, one could argue that a commit with only BREAKING CHANGE in the body, even if it's a bad practice, should be recognized as a breaking change and be parsed as such.
So I'm not sure if what you are reporting should be considered a bug or not.

In any case, if you think it's a bug, it should be reported to conventional-commits-parser as this is the library this plugin is using to parse commits. There is no much we can do in semantic-release.

from commit-analyzer.

I don't really have an opinion on whether or not it's a bug, but I think, if nothing else, we should update the documentation for semantic-release to make it clear that it's not going to work if BREAKING CHANGE is how the commit message terminates

I have four team members (including myself) who were very confused when their commit messages contained BREAKING CHANGE but didn't trigger a major bump. We ended up with several minor versions with breaking changes in them and that's not fun to triage

from commit-analyzer.

semantic-release uses the Angular commit format by default, but other format can be used via configuration. Whether a BREAKING CHANGE should have a description or not, is a implementation detail/choice of the commit format specification. semantic-release doesn't define the commit format specification, just use one by default.

This plugin's README, already provides a link to the Angular format specification that contains all the details.

The main semantic-release README provides a detailed explanation of commit format with a link to the Angular specification, and examples.

We even recommend tools to help with the commit format:

Tools such as commitizen, commitlint or semantic-git-commit-cli can be used to help contributor and enforce valid commits message.

I'm not sure what else can be added to the doc, to make clearer that there is a commit convention and following it is necessary for semantic-release to work.

from commit-analyzer.

The following example uses Angular convention but will consider a commit to be a breaking change if it's body contains BREAKING CHANGE, BREAKING CHANGES or BREAKING.

This section from the README is what's causing confusion. It's just inaccurate. The existence of those strings in the commit message is not what triggers a major version bump – it's those strings followed by more text

from commit-analyzer.

Ah ok! I see what you mean now.

What if we change that sentence to:

The following example uses Angular convention but will consider a commit to be a breaking change if conventional-commits-parser detect a valid BREAKING CHANGE, BREAKING CHANGES or BREAKING section in the commit body. By default the preset checks only for BREAKING CHANGE and BREAKING CHANGES.

And we can also change

Release rules are used when deciding if the commits since the last release warrant a new release. If you define custom release rules the default rules will be used if nothing matched.

to

Release rules are used when deciding if the commits since the last release warrant a new release. If you define custom release rules the default rules will be used if nothing matched. Those rules will be matched against the commits object resulting of conventional-commits-parser parsing.

from commit-analyzer.

I think that small change could save a lot of confusion for new people (like me) getting started!

from commit-analyzer.

Thanks @pvdlg !

from commit-analyzer.

reference https://gist.github.com/stephenparish/9941e89d80e2bc58a153
example:

feat($compile): simplify isolate scope bindings

Changed the isolate scope binding options

BREAKING CHANGE: isolate scope bindings definition has changed and
the inject option for the directive controller injection was removed.

from commit-analyzer.

I have the same issue using 6.0.1

fix: clean up type/interface names

BREAKING CHANGE: Renamed Options -> MachineOptions

from commit-analyzer.

I was having the same issue, upgrading to 6.2.0 seems to have worked.

from commit-analyzer.