Neither of them uses conventional commits

Both use semver

is somewhat meaningless because we don’t know the history since the last final release version

If you are in 1.0.0rc0 you know that either the API is being stabilized or there have been breaking changes. Any new patch or fix will be accumulated to the pre-release or will finally be released as 1.0.0.

Help me understand, and let’s look at this from another angle again. As a user, I want to start releasing candidates for my next major version: 2.0.0.
How would it look if we release a candidate coming from 1.9 for every following commit:

• breaking
• fix
• feat
• breaking
• fix
• feat

Could you list the versions until we make stable 2.0?

btw this is docusaurus using semver and cc
https://github.com/facebook/docusaurus/releases

Note:
I think can already customize yourself this behavior by doing your own version scheme and overriding the bump method.

Cf.

• https://github.com/commitizen-tools/commitizen/blob/master/commitizen/version_schemes.py#L96-L106
• https://commitizen-tools.github.io/commitizen/bump/#version_scheme

It doesn't mean that is use case doesn't need to be discussed, but that you can already customize it (while we need to agree on how this PR and behavior should be handled).

It initially wasn't meant to, but this is the beauty of making things extensible: you don't know what will come from the community with those extensions. Here's a perfect illustration.

No, I used some process to illustrate why the discussed behavior would make sense. The discussed behavior is how cz bump --prerelease beta (for example) is expected to behave in the face of a previous final release and one or more previous pre-releases.

(削除) Oh, I understood, and I tried to show you how it is your expectations' by showing you counter examples (the fact that PEP440 on which is based this soft is saying otherwise) and the fact that all 3 reviewers are reluctant to merge the PR in the current state might indicate that your expectations are not shared. (削除ここまで)
Sorry about that, not my place to tell and after review, not what I imagined. 🙏🏼

You might want to look at @woile’s comment #800 (comment) where he suggests using another command-line switch to refine the behavior of cz bump under a --prerelease switch.

Again, that’s what we’re discussing here.

I did and I even linked the answer in my previous response, there 👇🏼

(seems like the same idea as #800 (comment) but with the opposite flag and nominal case)

As I said, I have no issue with your workflow, I have an issue with making it the nominal behavior. Same as I would have an issue with making the "prevent feature commit on pre-release" the nominal behavior. Both are something which are tied to teams' usage and expectations.
I strongly think these kinds of changes should be opt-in or extensions based, not the normal behavior.

Hey @jenstroeger don't take it wrong, but I still have trouble understanding your comment on this particular case, why should it be removed? what is wrong with it?

I follow the logic of your other examples, but they are always for non-breaking changes. And you said this test case is irrelevant. But this test case, would be for a breaking change, how would the logic be?

If my understanding is correct, from any given version X, you can go to 3 possible pre-release versions (X + patch + pr, X + minor + pr, X + break + pr), and any new pre-release won't go beyond one of those 3 pre-release versions (depending on the given semver increment given). The final version will be one of those possibilities without the pre-release. Now if the example is 1.0.0rc0 why wouldn't the next version be 1.0.0?

This is how I think about the problem

graph LR;
 a[1.9.0]-->d[major: 2.0.0rc0]
 a[1.9.0]-->c[minor: 1.10.0rc0]
 a[1.9.0]-->b[patch: 1.9.1rc0]
 d --> e[major: 2.0.0rc1]
 c --> e
 c --> f[minor: 1.10.0rc1]
 b --> e
 b --> g[patch: 1.9.1rc1]
 b --> f
 e --> f1[2.0.0]
 f --> f1
 f --> f2[1.10.0]
 g --> f1
 g --> f2
 g --> f3[1.9.1]

And from 2.0.0rc0 I see only one option: 2.0.0. According to your comment, you propose going to 2.0.1

Apologies again for my struggle 😅 🙏🏻