"Breaking Change" not triggering major release

[simlu]

Current behavior

Using the following .releaserc.json file

{
  "analyzeCommits": {
    "preset": "angular",
    "releaseRules": [
      {"type": "feat", "release": "minor"},
      {"type": "fix", "release": "patch"},
      {"type": "perf", "release": "patch"},
      {"type": "docs", "release": "patch"},
      {"type": "chore", "release": false},
      {"type": "test", "release": false},
      {"type": "refactor", "release": false},
      {"type": "ci", "release": false},
      {"type": "amend", "release": false},
      {"scope": "no-release", "release": false}
    ],
    "parserOpts": {"noteKeywords": ["BREAKING CHANGE", "BREAKING CHANGES"]}
  }
}

breaking changes seem to not trigger a major release. Not sure if this is a bug or a configuration issue, please advice.

Expected behavior

Expecting a major release

Environment

• semantic-release version: Running semantic-release version 15.13.21
• CI environment: CircleCI (see link above)
• Plugins used: -
• semantic-release configuration: https://github.com/blackflux/lambda-tdd/blob/master/.releaserc.json
• CI logs: https://circleci.com/gh/blackflux/lambda-tdd/2482

[AlexisMasseron]

I do have the same problem, patch and minor version are triggered correctly but major version is never updated when adding "BREAKING CHANGE" to commit message

[simlu]

@AlexisMasseron Unlikely that you're have the same issue unless you're using a custom config. I suspect that you're not using the correct syntax instead. Take a look at the docs and check out my previous commit messages that correctly triggered a breaking change.

[pvdlg]

This is due to the way we process rules. For each commit we evaluate evaluate each of your rules, and if we find one that match we use it. IF we don't find then we look at the default rules.

Your commit is a fix and a BREAKING CHANGE. Because you have a rule that match fix and not that match a breaking change we use the fix one which trigger a patch.

In the default rules we have one (at the top) to match braking changes, but it's never evaluated as you have in your custom rule one that match your commit.

This is explained in the documentation: https://github.com/semantic-release/commit-analyzer#releaserules

To solve your problem you have to add {breaking: true, release: 'major'} at the top of your custom rules.

[simlu]

Hello @pvdlg ! Thank you very much for the swift reply! It is as always very much appreciated!

Fixed in blackflux/robo-config-plugin#478

Cheers, L~

[CheerlessCloud]

@pvdlg Hi 👋 I think that's very unintuitive behavior. What about in detail describe this case in the readme? Actually, README.md at master for now contains releaseRules without breaking: true but says that emit major release when BREAKING CHANGE exists in the commit message.

[abohannon]

I also can't get this to work. I'm not using a custom config and none of the following commit messages cause a major version bump.

BREAKING CHANGE: foo
breaking: foo
feat: this is a BREAKING CHANGE
feat: this is a breaking change

[travi]

@abohannon if you are not using a custom config, your issue is different from what was being asked in this closed issue. in the future, please open a new issue instead.

are you trying to create your commits with only a subject? be sure to instead include the BREAKING CHANGE: in the body of your commit since any type of commit could potentially be breaking for consumers, and is therefore independent of the commit type

[hamzahamidi]

If you're using Angular preset don't forget to add a Colon : after the keyword BREAKING CHANGE to trigger major release:

BREAKING CHANGE: foo