-
Notifications
You must be signed in to change notification settings - Fork 1
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
Use consistent parserOpts for commit-analyzer and release-notes-generator #143
Conversation
Any idea if we can back-port this as a patch to v1? Or will it just have to ship in v3 |
0c25fad
to
c60f604
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think backporting this would be ideal. We'd need to branch off the latest 1.x, 2.x releases and add them to the semantic release config for it to work: https://semantic-release.gitbook.io/semantic-release/usage/workflow-configuration#maintenance-branches
Would you like to try it out? 😄
PS: there's a snapshot test failing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we would also need to have a maintenance branch so this gets fixed in the v1
now that we have a new semantic-release action we might not have to backport this after all 😄 |
5fce0ba
to
90739fa
Compare
🎉 This PR is included in version 4.0.3 🎉 The release is available on: Your semantic-release bot 📦🚀 |
As per slack findings, we are passing these options to the release-notes-generator, but not to the commit-analyzer, which is why when using
BREAKING
orBREAKING CHANGES
, you would see correct release notes but the version still ended up as a minorAfter discussing this with @tagoro9 offline, we agreed to let both the commit-analyzer and the release-notes-generator use the default parserOpts