Developmental releases

[PsypherPunk]

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

[Lee-W]

Sounds like an interesting feature 🤔 @woile what do you think?

---

In our team, we usually merge / rebase the main / master branch back to feature branch so that commitizen can still handle the version bumping

[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.

[woile]

It does look good! Could you describe a bit the workflow? I'm wondering how are users expected to automate this. From what I gather there is a --devrelease N, but this implies manual input. How would you detect the current N in another branch and do N+1? Thanks!

[PsypherPunk]

Our immediate use-case is for CircleCI and that passes the CIRCLE_BUILD_NUM variable to each build job, which is a build-specific integer.

Passing --devrelease ${CIRCLE_BUILD_NUM} would allow for a branch-unique .dev suffix.

GitHub has similar functionality which could be leveraged to do the same…?

[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, @woile: PR raised as #582.

Regarding the tutorial you suggested, is there an example of how this should be done in the repo. that I could use as a reference point?

[woile]

@PsypherPunk if you have time to document this you can add it as a tutorial

sample docs/tutorials/dev_releases.md

# Dev Releases

Many CI's offer a build number, which can be leveraged by commitizen in order to create dev releases per branch.
bla bla bla

## CI Support

- drone-ci
- Jenkins
- gitlab
...

We also don't have a tutorial for drone-ci, so it would be appreciated a docs/tutorials/drone-ci.md one.

Thanks

[PsypherPunk]

PR raised, @woile: https://github.com/commitizen-tools/commitizen/pull/875

I've little to no experience with Drone CI, I'm afraid. I've added brief examples for CircleCI, GitHub and a more generic solution.