commitizen Bump increments to new pre-release version from pre-release version when it wouldn't from final version

Description

Running $ cz bump --prerelease beta when the current version is a previous pre-release bumps the version even when there are no commits that would require it, e.g. only build/ci commits.

Steps to reproduce

Start with a final version, e.g. v0.0.1
$ git commit -m "ci: CI-specific change not requiring release"
$ cz bump --prerelease beta -> Refuses to bump the version as expected
$ git commit -m "fix: Prospective fix requiring beta testing"
$ cz bump --prerelease beta -> Bumps to v0.0.2b0 as expected
$ git commit -m "build: Local devel change not requiring release"
$ cz bump --prerelease beta -> Bumps unexpectedly to v0.0.2b1

Current behavior

Maintainers can't use $ cz bump as a tool to interpret conventional commit messages to determine if a release is required when the current version is a pre-release. When some contributors are making build: .../ci: ... changes while features are in beta testing, this behavior results in a lot of noisy, meaningless v#.#.#b9999999.... bump commits, tags, and releases.

Desired behavior

Maintainers should be able to use $ cz bump, or $ cz ... in some other form, to determine if the conventional commit messages since the last pre-release require a new pre-release.

Environment

(build) rpatterson@rpatterson:~/src/devel/python-project-structure$ cz version --report
Commitizen Version: 2.42.1
Python Version: 3.10.6 (main, Nov 14 2022, 16:10:14) [GCC 11.3.0]
Operating System: Linux

Mar 16 '23 18:03 rpatterson

I just noticed the same behavior: with the --prerelease switch commitizen only ever increments the version once and then continues to bump the pre-release counter.

Furthermore, it increments on non-bump commit titles like chore: and it then also skips other bumps:

start at version 0.1.0
git commit --allow-empty --message 'fix: a fix'
cz bump --prerelease alpha → bumps to 0.1.1a0 which is ok
git commit --allow-empty --message 'feat: a feature'
cz bump --prerelease alpha → bumps to 0.1.1a1 which is incorrect, I would have expected 0.2.0a0 and we lost the “feature” bump
git commit --allow-empty --message 'chore: a chore'
cz bump --prerelease alpha → bumps to 0.1.1a2 which is surprising, but I guess could be ok (if the rest of the increments would work)
git commit --allow-empty --message 'feat!: a breaking change'
cz bump --prerelease alpha → bumps to 0.1.1a3 which is incorrect, I would have expected 1.0.0a0 (assuming we’re not in development mode to keep major version at zero) and we lost the breaking bump

There’s currently no official specification on how conventional commits should increment under a pre-release. However, comment https://github.com/conventional-commits/conventionalcommits.org/issues/398#issuecomment-969387687 makes a sensible suggestion for incrementing pre-release version numbers.

Any plan for cz to implement that soon?

May 15 '23 19:05 jenstroeger

I'm really not that convinced. I think we need a more formal definition of what a pre-release is and a longer explanation. I find it strange the possibility to go from 0.1.1a1 to 0.2.0a0 to 1.0.0a0 to 2.0.0a0 without ever doing a non-pre-release, feels like a strange workflow. Under which circumstance someone would develop a 3.0 without ever releasing 1.0?

I'm not against doing something about it per-se, but I think we need further thought on the topic.

What about controlling the version with --increment? forcing a more manual workflow? cz bump --increment MINOR --prerelease alpha, we could have a command like cz bump --increment-only in case someone wants to automate based on the commits, and from there: cz bump --increment $(cz bump --increment-only) --prerelease alpha?

May 16 '23 19:05 woile

I find it strange the possibility to go from 0.1.1a1 to 0.2.0a0

That's exactly what I expect if the commits require it. A v0.1.0 final release means a feature was released, right? If then a bug fix is released as a pre-release, it should be v0.1.1a1 because if it checks out and goes to final release, then that would be v0.1.1, right? If before v0.1.1a1 makes it to final release, someone merges a feature, then a pre-release for that should not be v0.1.1a2 because when it does make it to final release it should not be v0.1.1. When it gets to final release it should be v0.2.0, hence a pre-release containing that feature should be v0.2.0a0. If then, however someone merges another feature and a final v0.2.0 hasn't been released yet, then the pre-release for that second feature should be v0.2.0a1, not v0.3.0a0.

IOW, Commitizen should use changes since the previous release to determine if a new release is required but it should use changes since the previous final release to determine if the increment should be a patch, minor, or major bump.

May 16 '23 22:05 rpatterson

What @rpatterson said.

Whether a user publishes a release from a pre-release or not is a different matter. The question really is: given a pre-release tag & version and a series of fix: and feat: and chore!: commits can cz bump the next version correctly?

Currently it doesn’t, see above.

May 18 '23 08:05 jenstroeger

I realized I haven't already said it, but this specific tool is the closest I've found, including other tools (JS inclusive), to getting me to one-person CI/CD release publishing workflows based on conventional commits. So this nit-pick comes from real love.

May 18 '23 08:05 rpatterson

IOW, Commitizen should use changes since the previous release to determine if a new release is required but it should use changes since the previous final release to determine if the increment should be a patch, minor, or major bump.

This makes sense, I think we can work with something like that. I'll take a deeper look after holidays (june), unless someone wants to focus on it.

does this table summarize it well?

version	fix	feat	breaking
`0.1.1a0`	`*a1`	`0.2.0a0`	`0.2.0a0` or `1.0.0a0` (depending on major_version_zero)
`0.1.0a0`	`*a1`	`*a1`	`0.2.0a0` or `1.0.0a0` (depending on major_version_zero)
`1.0.0a0`	`*a1`	`*a1`	`*a1`

May 20 '23 17:05 woile

This makes sense, I think we can work with something like that. I'll take a deeper look after holidays (june), unless someone wants to focus on it.

Awesome, but just to be clear, I don't think of opening an issue as a demand that anyone in particular do something about it. ;-)

does this table summarize it well?

version fix feat breaking 0.1.1a0 *a1 0.2.0a0 0.2.0a0 or 1.0.0a0 (depending on major_version_zero) 0.1.0a0 *a1 *a1 0.2.0a0 or 1.0.0a0 (depending on major_version_zero) 1.0.0a0 *a1 *a1 *a1

Yup, looks right to me. Though personally I find it hard to get the point from that table. The prose description is more clear for me.

May 20 '23 20:05 rpatterson

does this table summarize it well?

@woile see also https://github.com/conventional-commits/conventionalcommits.org/issues/398#issuecomment-969387687.

May 21 '23 12:05 jenstroeger

A note to avoid duplication — we’re working on a change for this issue.

May 23 '23 21:05 jenstroeger