feat: use conventionalcommits as the default preset

[felipecrs]

Nowadays the conventionalcommits is the closest thing we have that looks like a standard and neutral.

Also, a new cli option was added: --preset.

BREAKING CHANGE: Previously, the default preset was angular. Despite the similarities, the new one has some differences, such as accepting exclamation marks (e.g. feat!:) for identifying breaking changes. To restore the previous behavior, use preset: angular' or the new cli option, --preset angular.

Closes #1652

[travi]

I'm supportive of this change, since I do think it makes more sense as the default now that things have evolved over time.

@semantic-release/maintainers, if you agree, what thoughts do you have around timing of introducing a breaking change like this? do we think the differences are enough to attempt more communication than would be included in the release notes of the major version bump?

[gr2m]

I'm in favor, too. I don't know if we have other breaking changes lined up, I'd suggest we do an audit, and assign issues we want to ship with the upcoming breaking version to a milestone.

But when in doubt, I'd rather ship it than waiting too long, it's an overdue change. Also the upgrade is trivial.

[atanunq]

Hello! I hope you don't mind me jumping in but are there plans to merge these changes? I am looking forward to setting up a semantic-release pipeline using only command line flags in a Makefile and this would come in very handy.

Your work is greatly appreciated!

[gr2m]

I think so, eventually. We have other priorities right now. Sorry it takes so long

[felipecrs]

I think this one can be included in 18.0 :)

[gr2m]

I think this one can be included in 18.0 :)

probably not in 18 because we want to get it out of the door quickly and are focusing on maintainability, but we can prioritize it for 19, which we can release soon after, together with some other priority changes. Stay tuned

[felipecrs]

Can this be included in v19?

[felipecrs]

I rebased the PR, just in case.

[travi]

Can this be included in v19?

this is still on our radar and is a change that i personally want to see move forward. however, v19 is targeting resolution of a few vulnerabilities and we don't want to delay it with verifying other changes or making acceptance of the vulnerability fixes more risky for consumers by including more changes than absolutely necessary.

[felipecrs]

Well, that was said for v18 as well. 😞

EDIT: the PR has all tests passing, and I really think no changes will be required at all. Perhaps it won't cause any noticeable delay if you give it a chance to review?

[travi]

Perhaps it won't cause any noticeable delay if you give it a chance to review?

more importantly, we don't want to add the surprise of switching conventions to consumers that are upgrading to get the vulnerability fix.

[travi]

I really think no changes will be required at all

also, we want to be sure that we are careful with this change so that release notes and other parts of the release process align properly without unexpected surprises. this convention has been the default from the beginning, so it would not be surprising if there are assumptions somewhere that we need to find and adjust.

[felipecrs]

Ok, no problem. Please let me know if there is anything I can do to help.

BTW, for most people migrating, there won't be any required changes to their workflow. They will just have to have in mind the new things that conventionalcommits supports (AFAIK it does not drop any feature from Angular, but adds on it). Like the ! for denoting breaking changes.