Breaking changes below v1 bump major version number

Description

The SemVer spec dictates that: “major version zero (0.y.z) is for initial development” and “Version 1.0.0 defines the public API.” A change during the initial development stage may be denoted as breaking, but there is little likelihood that implies the public API is stable. Bumping 0.y.z to 1.0.0 on the first breaking change encourages a common misconception of SemVer, that major version 0 is no different from any other. More importantly, this behavior can cause unstable software to be accidentally, abruptly, and irreversibly declared stable. It can still be helpful to consistently track which commits introduce breaking changes during initial development, and Commitizen supports a very clear syntax for doing that. If folks are not sure what cz bump will do, they can, of course, always run cz bump --dry-run. They may also use cz bump --increment MINOR in lieu of cz bump for breaking changes at major version 0, but this may be a hassle to configure when Commitizen runs in CI.

Steps to reproduce

1. Create a new project with major version 0.
2. Run cz commit.
3. Select feat.
4. Declare the change breaking.
5. Complete the commit.
6. Run cz bump.

Current behavior

cz bump bumps to 1.0.0.

Desired behavior

At major version 0, cz bump bumps the minor version number for all feat changes, breaking or otherwise. Behavior is unchanged when major version > 0.

Screenshots

No response

Environment

Commitizen Version: 2.24.0 Python Version: 3.10.4 (main, Apr 5 2022, 17:28:03) [GCC 11.2.0] Operating System: Linux

[jenstroeger]

Definitely a required feature, I agree. The semantic-release tool provides a major-on-zero config setting for this purpose.

My personal take on this would be to add a command-line switch --major-version-zero for bump and a configuration setting major_version_zero = true which keeps the major version at zero. Always. It would be the equivalent of

bump_map = {"break" = "MINOR", "new" = "MINOR", "fix" = "PATCH", "hotfix" = "PATCH"}

plus the added assertion that the current major version is zero.

If at some point the software reaches maturity, users can remove that major-version-zero setting using a feat!: commit which would then bump to v1.0.0.

The setting should issue a warning if used for existing versions greater than zero.

[woile]

I really like this proposal @jenstroeger. Anyone wants to pick this up?