Update major for breaking changes in 0.x versions by default

[sandzhaj]

Is your feature request related to a problem? Please describe.
I find it non-intuitive when we don't update the major version for breaking changes in 0.x versions. I use git-changelog and commitizen together. Right now, I have to use 'major-version-zero=true' because that's the only option in git-changelog."

Describe the solution you'd like
Add arg --major-version-zero like in commitizen: https://commitizen-tools.github.io/commitizen/bump/#-major-version-zero
By default, we can update the major version, and if we use that param, we will update minor.

[pawamoy]

Hello, thanks for the feature request.

git-changelog's behavior is based on semver's spec:

5. Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

8. Major version X (X.y.z | X > 0) MUST be incremented if any backward incompatible changes are introduced to the public API. It MAY also include minor and patch level changes. Patch and minor versions MUST be reset to 0 when major version is incremented.

So, with the current behavior, breaking changes trigger a major bump only if major version is greater than 0. It means you can iterate fast and break things without worrying about your major version suddenly being bumped to 1. Once you are ready to bump to 1, you do so explicitly (unreleased features will help, let me publish a new version). It happens only once, and then you can continue relying on git-changelog behavior, which will now bump the major version for breaking changes. IMO putting this automatic behavior, which is compliant with semver's spec, behind a flag, would deteriorate the user experience.

Also, from the link you posted:

Remove that configuration using a breaking-change commit to bump your project’s major version to v1.0.0 once your project has reached maturity.

I don't think that's a good workflow, requiring users to voluntarily add a breaking change, or at least mark a commit as breaking even if it is not, just to bump to 1.0.0. Bumping to 1 from 0 does not necessarily mean there is a breaking change, it simply means your API is stable and ready for production.

Therefore I'm inclined to say no to this feature! Happy to discuss this further 🙂

[pawamoy]

OK, version 2.3.0 published, you can now use git-changelog --bump 1.0.0 when you are ready to bump from 0 to 1.

[sandzhaj]

5. Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
6. Major version X (X.y.z | X > 0) MUST be incremented if any backward incompatible changes are introduced to the public API. It MAY also include minor and patch level changes. Patch and minor versions MUST be reset to 0 when major version is incremented.

However, these claims do not contradict my approach.

git-changelog does not draw attention to breaking changes if you have a version 0.x. As a result, my CHANGELOG.md currently looks no different, whether I make a commit feat: new feature or feat!: new feature.

In feat!: new feature with 0.x, the ! becomes a useless and non-influential flag in git-changelog. Why fear a major version update when you can simply avoid using the breaking flag? It's logical that by using the breaking flag with semver, we intend to update the major version.

Therefore, we simply allow users to choose their workflow. The proposed implementation is taken from commitizen, which also based on the semver's spec. I think you won't deny that.

I could use commitizen for all my needs, but for changelogs, git-changelog looks more appealing due to its configurability and versatility. In commitizen, I can't customize the output using templates, but when it comes to workflow organization, they provide the user with flexibility.

Perhaps we can add this feature, modifying it in a way that the default remains as you prefer, while we, the users, have the ability to override it in the same pyproject.toml?

[sandzhaj]

I don't think that's a good workflow, requiring users to voluntarily add a breaking change, or at least mark a commit as breaking even if it is not, just to bump to 1.0.0. Bumping to 1 from 0 does not necessarily mean there is a breaking change, it simply means your API is stable and ready for production.

I completely agree. I didn't suggest such a workflow. You should only add the breaking change flag when it's truly necessary.

With my approach, you don't need to add the flag 'forcefully'. You simply have a choice: you can switch to the new version using feat!: new feature and git-changelog --bump 1.0.0.

It all depends on the situation. For instance, I automatically update the version and Git tag using commitizen, and I have set major-version-zero = false.

So, if I make a commit feat!: new feature, in my CI system git-changelog (bump=auto) will be triggered, then cz bump (this command will create a new 1.0.0 tag).

As a result, I'll get a 1.0.0 release where, in CHANGELOG.md, the bump worked incorrectly and set, for example, 0.1.0 instead of 1.0.0.

[pawamoy]

OK so the actual use case is continuous deployment. We currently provide a way to bump manually when ready for v1, but no "automated" way from configuration only. Let me think about how I'd like to handle this :)

[sandzhaj]

Sure, maybe I should start with that. I always thinking about CI/CD :D