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
I would still like to track the breaking changes being made to the API using conventional commits so we can easily communicate to early adopters that the API did change.
The current behavior is to perform a major release version bump on all BREAKING CHANGES. I propose that for versions < 1.0.0 that BREAKING CHANGE commits only trigger a minor release.
The text was updated successfully, but these errors were encountered:
Hi @nathanielc ! Thank you very much for your feedback.
The current behavior is to perform a major release version bump on all BREAKING CHANGES. I propose that for versions < 1.0.0 that BREAKING CHANGE commits only trigger a minor release.
If follow this rule, how do I change the version from < 1.0.0 to 1.0.0 ? always manually ?
Yes,it would always be a manual process. that way the developers explicitly choose when to say that their API is now complete and will no longer break in future minor releases.
According to semver the API may change with releases before the 1.0.0 release. https://semver.org/#spec-item-4
I would still like to track the breaking changes being made to the API using conventional commits so we can easily communicate to early adopters that the API did change.
The current behavior is to perform a
major
release version bump on all BREAKING CHANGES. I propose that for versions < 1.0.0 that BREAKING CHANGE commits only trigger a minor release.The text was updated successfully, but these errors were encountered: