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
feat: use conventionalcommits
as the default preset
#1836
base: master
Are you sure you want to change the base?
feat: use conventionalcommits
as the default preset
#1836
Conversation
231dcdd
to
dbed860
Compare
1bf6e76
to
9dba09c
Compare
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? |
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. |
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! |
I think so, eventually. We have other priorities right now. Sorry it takes so long |
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 |
Can this be included in v19? |
9dba09c
to
adb9c79
Compare
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 semantic-release#1652
adb9c79
to
ed083e7
Compare
I rebased the PR, just in case. |
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. |
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? |
more importantly, we don't want to add the surprise of switching conventions to consumers that are upgrading to get the vulnerability fix. |
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. |
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 |
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, usepreset: angular'
or the new cli option,--preset angular
.Closes #1652