Developmental releases

Description

We’re running into issues using commitizen for version-bumping where, if people are working on the same repository simultaneously on different branches, our CI process will bump them to the same version, leading to a collision when tagging.

Previously, we’ve used a CI-specific suffix to get around this and, as per PEP 440, “Developmental releases” “may be useful for continuous integration purposes…”.

The docs currently state: “post and dev releases are not supported yet” so this may be a useful feature for anyone with a similar workflow…?

Possible Solution

I’ve made an initial attempt at this over here.

Here, --devrelease has been added as a flag that takes an explicit “non-negative integer value” and simply uses that as part of the .devN component of the version, e.g. passing --devrelease 1234 results in a developmental release segment of .dev1234.

It does not attempt to infer the version based on the current version: doing so would run counter to the continuous-integration use-case and potentially result in a collision as per the Description.

Additional context

No response

Additional context

No response

[woile]

Nice! I think that could work, PR’s welcome. Maybe add a tutorial explaining how to do devreleases, it would be great.

Thanks!

[PsypherPunk]

Thanks, @Lee-W.

We tend to follow the same workflow: the above only really arises when we have more than one active branch. If we’re actively pushing to those branches, because each is relative to main and unaware of the other, they end up vying for version numbers.

When one gets merged, as you say, any remaining branches can be rebased and it’s less of a problem.