support bang syntax for breaking changes #2306
-
I know it's not in the original Angular spec, but https://www.conventionalcommits.org/en/v1.0.0/ does outline the bang syntax ( Maybe some additional context: |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 1 reply
-
semantic-release uses the angular convention by default, which does not support the syntax you mention. you can choose the conventional-commits convention instead, which supports that syntax. we intend to make that the default convention at some point, but for now you have to switch your convention in your config. |
Beta Was this translation helpful? Give feedback.
-
Got it. I thought it was using conventional as the default. Thanks for the response. |
Beta Was this translation helpful? Give feedback.
-
I have this in the release config: plugins:
- '@semantic-release/commit-analyzer' which uses conventional-changelog -- I had assumed that the various projects under After reading through the docs a few times, I did figure it out; to put it here in case anyone else is searching: % npm install --save-dev conventional-changelog-conventionalcommits and then plugins:
- - '@semantic-release/commit-analyzer'
- preset: conventionalcommits |
Beta Was this translation helpful? Give feedback.
-
It's also necessary to configure Also, don't fall into the trap of specifying only the presets that you're configuring. If you specify So if you want the default semantic-release configuration but with Conventional Commits, the full configuration is: plugins:
- - '@semantic-release/commit-analyzer'
- preset: conventionalcommits
- - '@semantic-release/release-notes-generator'
- preset: conventionalcommits
- '@semantic-release/npm'
- '@semantic-release/github' and: npm install --save-dev conventional-changelog-conventionalcommits It's almost impossible to figure this out from the docs, it took me a lot of trial and error. |
Beta Was this translation helpful? Give feedback.
semantic-release uses the angular convention by default, which does not support the syntax you mention. you can choose the conventional-commits convention instead, which supports that syntax. we intend to make that the default convention at some point, but for now you have to switch your convention in your config.