"BREAKING CHANGE:" and "!" after type not properly triggering major release

[dgattey]

I've seen the other issues like this that are already closed (#108)! But I believe this is different. BREAKING CHANGE: appears at the beginning of the footer, yet the release is only minor.

Here's the output from https://github.com/dgattey/dg/runs/2444677702?check_suite_focus=true

[4:18:45 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: chore: swapping to a hopefully-better codegen
[4:18:45 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The release type for the commit is patch
[4:18:45 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: feat: pull data from Contentful dynamically to populate the pages

Just the id for now, but coming soon, all the data!

BREAKING CHANGE: fully overhauls the content creation & usage - all data now controlled
directly by Contentful. There should be no strings outside basic site metadata checked into
the repo from now on!
[4:18:45 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The release type for the commit is minor
[4:18:45 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: feat: includes graphql types codegen automatically
[4:18:45 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The release type for the commit is minor

[dgattey]

Okay, read up on conventional commits and tried the ! operator after the subject and that actually did work. I'm using the angular present though, which would make me think that BREAKING CHANGE in the footer is a valid way to bump the major version. Am I missing something obvious here?

Full configuration available in release in https://github.com/dgattey/dg/blob/main/package.json.

[alehar9320]

I also managed to overcome this issue by adjusting header by adding exclamation mark to type/scope and adding BREAKING CHANGE: to the footer.

Example commit - Fail

breaking change: this is a breaking change

This is a breaking change. BREAKING CHANGE.

breaking change

Based on Conventional Commit standard / Angular JS project standard, I applied both of the specified formats for triggering a release - type/scope and footer. Then got it to work successfully.

I think it's fair to close this issue and rather bring up a discussion in the conventional commits standard community. It does feel a bit strange though that the commit analyzer is sensitive to whether there is an exclamation mark and whether it is upper or lower case, etc. I wouldn't be opposed to the idea of the tool providing some smart assistance to the developer. Possibly, using some wiggle room to complement the standard's specifications.

Example commit - succeeded

BREAKING CHANGE!: this is why I broke something

BREAKING CHANGE:

Log output in pipeline:

npx semantic-release@17
...
[11:26:25 AM] [semantic-release] › ℹ  Running semantic-release version 17.4.2
...
[11:26:32 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: BREAKING CHANGE: inc major version number
Semantic release did not trigger on previous commit. Will try a commit explicitly aimed at triggering a new release. This is linked to UX-123. Update prefix from 'banana' to 'savanna'.
BREAKING CHANGE!
[11:26:32 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The commit should not trigger a release

Dependencies include:
"@semantic-release/changelog": "^5.0.1",
"@semantic-release/git": "^9.0.0",

.releaserc.json

  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    [
      "@semantic-release/npm",
      {
        "pkgRoot": "dist/libs/my-lib",
        "npmPublish": true
      }
    ],
    "@semantic-release/changelog",
    "@semantic-release/git"
  ],
  "preset": "angular",
  "repositoryUrl": "git+ssh://my-user@bitbucket.org/some-pd/myrepo.git"
}```

[dgattey]

@alehar9320 that's not going to work regardless since you need BREAKING CHANGE: (note the colon) to start the "footer" section of the commit (the last paragraph) as far as I understand. But my problem was that even with the colon, it wasn't triggering it. Your commit in the log has BREAKING CHANGE: in the subject, and the example commit doesn't have BREAKING CHANGE: starting a new paragraph.

Regardless, it's not well documented, and seems to not be working properly as according to the Angular preset. Little mystified here.

If you try a commit message like this, it should work (assuming fix is valid to start a commit for your setup). The ! in the subject is what did it for me:

fix!: inc major version number
Semantic release did not trigger on previous commit. Will try a commit explicitly aimed at triggering a new release. This is linked to UX-123.

BREAKING CHANGE: Update prefix from 'banana' to 'savanna'.

[darrylhodgins]

Adding my +1 here. According to the Conventional Commits spec, adding only the exclamation mark after the type should trigger a major increment. Instead, I'm getting There are no relevant changes, so no new version is released.

From Conventional Commits 1.0.0:

BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.

[julianpoy]

@darrylhodgins experiencing this too

[cdelcos]

Any update on this ?

[unional]

[10:19:02 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: fix!: drop node 8 support

This enable ESM usage as in ESM `require()` is not supported.
[10:19:02 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The commit should not trigger a release

I encountered this issue too.
https://github.com/unional/assertron/runs/7825742919?check_suite_focus=true

[aleclarson]

Here's a workaround. Put this in the plugins array of your release config:

[
  '@semantic-release/commit-analyzer',
  {
    preset: 'conventionalcommits',
  },
],
[
  '@semantic-release/release-notes-generator',
  {
    preset: 'conventionalcommits',
  }
],

You need to use release.config.js instead of JSON config.

Then install conventional-changelog-conventionalcommits.

[texhnolyze]

I did a deep dive on this and think the way it is, is counterintuitive when expecting Conventional Commits 1.0.0 to apply.

However as the default ruleset/parserConfig is using conventional-changelog-angular and the corresponding commit message guidelines of angular do not adhere to the rule declaring breaking changes by exclamation mark like: feat(abc)!: ..., I think the current behaviour is correct.

As @aleclarson noted, if you want to apply the rules of the conventional commits spec, then you can configure that as the preset to use.

If this should be fixed in the angular rules, it needs to be done in the conventional-changelog angular parser options by introducing:

 breakingHeaderPattern: /^(\w*)(?:\((.*)\))?!: (.*)$/,

As in the parser options of convetional commits.

Another but different discussion is, if the default ruleset of the commit-analyzer should be switched from angular to conventional-commits, as people (me included) were/are expecting adherence to those specifications.