Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
dgattey opened this issue Apr 27, 2021 · 13 comments
Open

Comments

@dgattey
Copy link

dgattey commented Apr 27, 2021

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
Copy link
Author

dgattey commented Apr 27, 2021

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
Copy link

alehar9320 commented Apr 27, 2021

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://[email protected]/some-pd/myrepo.git"
}```

@dgattey
Copy link
Author

dgattey commented Apr 27, 2021

@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
Copy link

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
Copy link

@darrylhodgins experiencing this too

@dgattey dgattey changed the title "BREAKING CHANGE:" not triggering major release "BREAKING CHANGE:" and "!" after type not properly triggering major release Nov 9, 2021
@cdelcos
Copy link

cdelcos commented Jul 26, 2022

Any update on this ?

@unional
Copy link

unional commented Aug 14, 2022

[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
Copy link

aleclarson commented Sep 6, 2022

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
Copy link

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.

@kddsultan
Copy link

Please add some support to at least to override this option

@kddsultan
Copy link

kddsultan commented May 23, 2024

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.

Setting conventionalcommits also suggested by @texhnolyze seems also more logical to me (than angular preset) as default

@BinToss
Copy link

BinToss commented May 30, 2024

If using the conventionalcommits preset, then this was resolved in https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-conventionalcommits at some point.
It handles the title's shebang and breaking changes footer as expected. You can use one, the other, or both to indicate breaking changes.

@guidojw
Copy link

guidojw commented Dec 6, 2024

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.

This workaround doesn't work for me.
I am using a .releaserc file, is that an important detail?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests