pre releases optionally start with a non-zero value

[ckagerer]

Description

I am C developer in microcontroller environment. So far I always used my own scripts/tools to increment version numbers and manually updated the changelog (if I didn't forget ;)).

I have been successfully using commitizen for my utilities in Phython for a few months now and would like to use that for embedded projects as well. But I currently have a problem that prevents me from using it. In our company the version is stored as four bytes in the embedded devices. MAJOR.MINOR[.BUGFIX][bBETA]. The BUGFIX and BETA digits are optional and are filled with zero if these digits should not be displayed by our ServiceTool.
With the BUGFIX everything still works perfectly (example: 0.3.0 -> 0.3.1 ✓).
However, with a PRERELEASE there is a conflict with our encoding (example: 0.3.0 -> 0.3.1b0 ⨯).
The only thing I would need to be able to use this great tool there would be an offset setting for prereleases so that the above example becomes this: 0.3.0 -> 0.3.1b1 ✓.

Possible Solution

My proposed solution see PR #614 .
=> The introduction of a configuration for the offset. With this one can easily reconfigure the deviating behavior depending on the project.

Additional context

No response

Additional context

No response

[woile]

Hey @ckagerer thanks for the input and the proposal. We recently introduced the --devrelease flag to bump. So you can do

cz bump --devrelease 1

Would you be able to work with that?

I think the docs could be improved, but here's the discussion that may be relevant for you: #570 (comment)

[ckagerer]

Hey @ckagerer thanks for the input and the proposal. We recently introduced the --devrelease flag to bump. So you can do

cz bump --devrelease 1

Would you be able to work with that?

I think the docs could be improved, but here's the discussion that may be relevant for you: #570 (comment)

Hi @woile,
Thanks for the quick suggestion of an alternative.
The devrelease option is unfortunately not quite suitable for my case.

1. We need tags b{NUMBER} and not .dev{NUMBER}, because the tag is also used as folder name on our software archives. Here this style break would lead to confusion for many non-software developer colleagues. I could let an own script after cz bump correct the tag and the version number in the CHANGELOG, but I find this unsightly and very error-prone.
2. We are increasingly moving towards automating the release process via our CI. This means that the developer only starts the create [beta] release job and everything else happens automatically. Therefore the explicit specification, as it is necessary with the --devversion, is to be determined and set automatically. Here exactly the same logic which is already present in commitizen would have to be rebuilt externally, so that the CI knows whether it must count up or must start again with 1.

Considered together, quite a lot of logic would be built around commitizen.
By the approach as I suggested it in PR #614 I would have to set in my case in the configuration in the Repo only the prerelease_offset=1. And in the CI process for a bump either cz bump or cz bump --prerelease beta call. That's it, no more scripts for adjustments to our guidelines in post-processing.

Best regards,
Christian

[woile]

I'll review the proposal. @Lee-W do you have any thoughts about it?

Here exactly the same logic which is already present in commitizen would have to be rebuilt externally, so that the CI knows whether it must count up or must start again with 1.

I may be misunderstanding. But if you have 2 users that created branches from main, and both of them try to make a beta release, they would get the same numbers, right? How would you prevent that? The --devversion parameter normally goes next to some CI environment variable --devversion $BUILD_NUMBER.

[ckagerer]

I may be misunderstanding. But if you have 2 users that created branches from main, and both of them try to make a beta release, they would get the same numbers, right? How would you prevent that? The --devversion parameter normally goes next to some CI environment variable --devversion $BUILD_NUMBER.

This would indeed be a possible error case.
Specifically, we use Jenkins and here I would have this behavior also with --devversion $BUILD_NUMBER, because in a multibranch pipline each branch has its own build counter. So this is already a case that can be caught by the release process rather than by the tool.
In our company we catch this case by the fact that our release process can only be started in the main/master branch. If you want to release something in a featrubranch, you can only do this with a local version.

[Lee-W]

Hi @woile @ckagerer , sorry for the late reply. I'm good with the idea. Let me review the branch now 👍

[ckagerer]

is done with the merge of pr #614