Breaking changes should not raise the major version for the project in version 0.y.z
piotrminkina opened this issue · comments
Hello,
As I read on https://www.conventionalcommits.org/en/v1.0.0/ theoretically commit with BREAKING CHANGE: or the character ! after the type/scope shoult bump up major part of Semantic Version, but it is not truth for versions 0.y.z. On the page https://semver.org/ we can read:
Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
So as long as we work on version 0.y.z of the project, any breaking changes are allowed, and the major version should not be bumped up until it is up to version 1.y.z or higher. Marking commits with BREAKING CHANGE: or with a ! sign is valuable and should also be posible in version 0.y.z of the project, but as above, without raising the major version.
Regards
Piotr Minkina
Hi @piotrminkina ,
I'm not sure I got the point. Are you suggesting the breaking change modifier should be ignored as long as the major version is 0?
@flelli Exactly. According to Semantic Versioning, any changes on 0.y.z that break backward compatibility are allowed. That's what the 0.y.z branch is for, to shape and stabilize the public API.
Anything MAY change at any time. The public API SHOULD NOT be considered stable.
In order for consumers to know when exactly a breaking change goes in, such information in the commit message as BREAKING CHANGE, or feat!: are very helpful, but as above they should not cause the major part to be raised. It is precisely such behaviour that is in line with Semantic Versioning, so I report the current behavior as a bug.
On the other hand, how would one make Nyx bump the major version when it's time?
I believe this behavior must be in control of users. They can publish releases containing breaking changes (in the 0 major version, but in any versio as far as Nyx is concerned) without bumping the major. It's up to project maintainers to decide whether to bump the major or not.
@flelli The time when version 1.0.0 is to be released fully should be up to the decision of the maintainer, because with the release of version 1.0.0 he gets a commitment that the public API will not contain breaking changes until he wants to bump up the next major version. Nyx, based on whether the version of the project is 0.y.z or 1.y.z and higher, should decide whether, in the case of a commit message with a breaking change, it bumps up the major version part or not.
I think this behaviour could be implemented with regular expressions in https://mooltiverse.github.io/nyx/guide/user/configuration-reference/commit-message-conventions/#bump-expressions, but I guess there would have to be access to the latest released version of the project here.
The point is: how could Nyx make the decision? It would end up creating a custom commit message convention, which would be just cumbersome (and unused).
I don't think there's anything wrong or misleading with the standard behavior, where maintainers decide. It's up to them to include breaking changes in version 0 or bump the major.
In the case of Gradle's nyxInfer task or others, this could be handled by an additional parameter, such as --release-version=1.0.0 or --release-next-major.
Yes, it is up to the maintainer to decide when to release the next major version, but by agreeing to version with Semantic Versioning he is agreeing to the conventions adopted in this standard, otherwise he should not announce that he is using Semantic Versioning, as this would mislead consumers.
As a consumer of software versioned with the Semantic Versioning standard, I know that as long as I use version 0.y.z, I can safely use in my dependency version declaration, for example, a range like this: <0.2.0,0.3.0) (mathematical right-open range). Any time I decide to use a next minor version then I should take a close look at the changes in the project changelog. Here I would especially look for something like BREAKING CHANGE:, or feat!. In case of use version 1.0.0 or later, I can safely use a looser dependency version declaration, such as <1.0.0,2.0.0), because according to Semantic Versioning, any version from 1.0.0 inclusive up to 2.0.0 exclusively must have a stable public API.
So Semantic Versioning is for both software developers and consumers (usually also software developers). Conventional Commit introduces a nice convention for signaling breaking changes. Combining the two standards in the right way should, in effect, increase the likelihood of making the right decisions on the part of both the software maintainer and its consumer.
There's no need of an additional parameter to force a version because users can already use the version or the bump parameters.
The current behavior does not violate SemVer by any means. On the other hand, not bumping the major version in case the maintainer marks the version as a breaking change, would lead to inconsistencies because when a maintainer does so, she/he intentionally wants to bump it.
As a consumer of software versioned with the Semantic Versioning standard, I know that as long as I use version 0.y.z, I can safely use in my dependency version declaration, for example, a range like this: <0.2.0,0.3.0) (mathematical right-open range). Any time I decide to use a next minor version then I should take a close look at the changes in the project changelog. Here I would especially look for something like BREAKING CHANGE:, or feat!. In case of use version 1.0.0 or later, I can safely use a looser dependency version declaration, such as <1.0.0,2.0.0), because according to Semantic Versioning, any version from 1.0.0 inclusive up to 2.0.0 exclusively must have a stable public API.
This still holds true, but it looks like there's a bit of confusion between the words CAN and MUST. and also what is addressed by SemVer and Conventional Commits. The two get along well, but they're not the same. Let me explain.
From the SemVer perspective, the fact that a maintainer CAN issue versions containing breaking changes below major 0 doesn't mean she/he MUST.
From the Conventional Commit perspective, a breaking change MUST bump the major version, even if the previous one was 0, and that's the behavior you expect when you combine SemVer and Conventional Commits.
You are free to define a different commit message convention and also have it supported by Nyx, but that would not be Conventional Commits.
@flelli I think you're right. Out of curiosity, however, I linked to a discussion in the conventional-commits/conventionalcommits.org#528 open thread where the author also sees inconsistencies between Semantic Versioning and Conventional Commits.
I'm glad we clarified this point, also for future readers.