Bump minor/patch version only when major version is 0

Description

Quote from Specification Item 4, Semantic Versioning 2.0.0:

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 it is reasonable to remain major version with zero even if there is a breaking change commit, i.e. bump version at minor level (0.y+1.z).

Use cases

I have a new project with major version of zero. The API may change before I release it to public. I want to use python-semantic-release to help me to tag and release to internal team, with a major version of zero to indicate it is in development stage.

Without the requested feature, if I change API, I have to remove BREAKING CHANGE warning in commit message (this is bad), or have to remember adding --minor flag when firing semantic-release command (this is not reliable).

With the requested feature, I only use --major flag manually to bump the version to 1.0.0 when I decide the project is stable enough to release to the public. All the other semantic-release publish commands will bump at the correct level automatically.

Possible implementation

Modify evaluate_version_bump function to return "minor" instead if current_version has major version of zero and the calculated bump have a value of "major".

I’d like to contribute a pull request if this is acceptable.

[danth]

@wyardley I’d write major_on_zero to match the existing option patch_without_tag.

Maybe a name like zero_is_unstable would be easier to understand?

[danth]

Although it fits the specification, I don’t think we can enable this by default because users may rely on the previous behaviour. Therefore a configuration option will be needed.

I’d also suggest having a way to trigger the bump to v1.0.0 using a commit message.