Breaking changes

[koifmanc]

Breaking changes should contain BREAKING CHANGE: in the commit message body.
When using lerna without adding this message version won't be bumped.
according to spec ! is only to draw attention.

[lppedd]

Hey there! It's unclear to which part of the plugin you're referring to. If it's related to a specific functionality, could you post a screenshot?

[bojovypstros]

@koifmanc look to two other examples above the one you linked. Those are valid commit messages examples and there is only exclamation mark to draw attention and no BREAKING CHANGE body is present.

[koifmanc]

Hey there! It's unclear to which part of the plugin you're referring to. If it's related to a specific functionality, could you post a screenshot?

Commit message body should have the text BREAKING CHANGE:
the exclamation mark is not enough

[koifmanc]

@koifmanc look to two other examples above the one you linked. Those are valid commit messages examples and there is only exclamation mark to draw attention and no BREAKING CHANGE body is present.

I understand that the exclamation is supposed to be enough but unfortunately, some tools like Lerna ignore it and won't bump the version so maybe it's possible to add it

[lppedd]

@koifmanc the problem with the proposal is that it adds an empty BREAKING CHANGE:. This is not in the Conventional Commit standard and if you think about it, it makes no sense. If you want the BREAKING CHANGE footer, the real solution is to add an actual breaking change description.

[bojovypstros]

I understand your problem, but since this repo directly depends on conventional commits rules and number 13 says:

If included in the type/scope prefix, breaking changes MUST be indicated by a ! immediately before the :. If ! is used, BREAKING CHANGE: MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change.

in my opinion there is no requirement to add the footer key since it is not required. I think the problem should be reported to Lerna. The second problem, with your provided enhancement is that it breaks rule number 12:

If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g., BREAKING CHANGE: environment variables now take precedence over config files.

since it does not provide the BREAKING CHANGE description. Source: https://www.conventionalcommits.org/en/v1.0.0/#specification

[koifmanc]

I understand your problem, but since this repo directly depends on conventional commits rules and number 13 says: If included in the type/scope prefix, breaking changes MUST be indicated by a ! immediately before the :. If ! is used, BREAKING CHANGE: MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change. in my opinion there is no requirement to add the footer key since it is not required. I think the problem should be reported to Lerna. The second problem, with your provided enhancement is that it breaks rule number 12: If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g., BREAKING CHANGE: environment variables now take precedence over config files. since it does not provide the BREAKING CHANGE description.

Sure, I understand the problem of adding an empty BREAKING CHANGE: without any description, I proposed that change mainly because of an issue with lerna which is open since July 2020 :( ...
lerna/lerna#2668

[bojovypstros]

@koifmanc I see your problem now. This is very disappointing but there is no other option but hope that Lerna is going to fix this issue. Gonna write my opinion in the bug you mentioned.

[bojovypstros]

@koifmanc I see now that they use Angular commits changelog semantics which is why the conventional commits are not working properly. In the issue thread there are some work-arounds where you can use conventional commits and bypass the angular changelogs.

@lppedd I think you can close this issue now.

[lppedd]

This plugin exposes an API which can be used by other plugins.

I'll keep this open as an additional interface to let other plugins modify the dialog behavior might be a good idea.