You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We maintain a custom conventional changelog link that we would like to use with semantic-release, but any time we've tried this, any time we merge a PR it's treated as a breaking change because of this line right here:
This breaks our conventional changelog because we maintain detailed notes for each of the commits inside of a squashed commit. We use this in other places to analyze the squashed commits to determine what the correct release type is. For example, if a commit looks like this:
fix: Something small
* feat: Add a feat
Then the correct release for that squashed commit would be a feat. Semantic release has this concept itself when multiple commits are released at once, we do the same thing just at a PR level.
That problematic line above means that any PR that is squashed is treated as a breaking change though, which means we end up having to maintain a separate set of release rules which defeats the whole purpose of creating a conventional-changelog for our org.
IMO that line should be changed to scan for BREAKING CHANGE in the notes instead of default treating the presence of a note s a breaking change.
The text was updated successfully, but these errors were encountered:
We maintain a custom conventional changelog link that we would like to use with semantic-release, but any time we've tried this, any time we merge a PR it's treated as a breaking change because of this line right here:
It treats any commit note at all as a breaking change. I'm pretty sure this is because the angular conventional discards all notes unless they are a breaking change https://github.com/conventional-changelog/conventional-changelog/blob/master/packages/conventional-changelog-angular/writer-opts.js#L31-L34 (I checked a few other conventional changelogs and did not see them using the
notes
field at all).This breaks our conventional changelog because we maintain detailed
notes
for each of the commits inside of a squashed commit. We use this in other places to analyze the squashed commits to determine what the correct release type is. For example, if a commit looks like this:Then the correct release for that squashed commit would be a feat. Semantic release has this concept itself when multiple commits are released at once, we do the same thing just at a PR level.
That problematic line above means that any PR that is squashed is treated as a breaking change though, which means we end up having to maintain a separate set of release rules which defeats the whole purpose of creating a conventional-changelog for our org.
IMO that line should be changed to scan for
BREAKING CHANGE
in the notes instead of default treating the presence of a note s a breaking change.The text was updated successfully, but these errors were encountered: