Rethink version bumping policies in taurus
current practice
The current practice for bumping versions in taurus is as follows:
- taurus uses semantic versioning
- bumpversion is used to manage versions
- the current bumpversion configuration supports versions of type
major.minor.patch[-alpha]
. It allows bumping the "major", "minor" and "patch" components plus an special "release" bump. Bumping major, minor and patch always adds the "-alpha" suffix, and bumping the "release" removes it. - The taurus "official releases" (i.e. those pushed to the
stable branch
and tagged) require "release" bump (i.e. they do not have the "-alpha" suffix) - In contrast, in the development branch, there may occur "major" "minor" or "patch" bumps, but not "release bumps" (i.e. the versions in the develop branch always have the "alpha" suffix). The various "unreleased" versions in develop may be referred tointernally in the code (e.g. in deprecation warnings, docstrings or comments).
problems of current practice
The current practice becomes problematic when combined with gitflow's hotfix releases. Consider the following (real) case:
- taurus 4.7.0 is released
- immediately, the version in the develop branch is bumped to 4.7.1-alpha
- work occurs on the development version for which the path is bumped (e.g. 4.7.1-alpha --> 4.7.2-alpha --> ... --> 4.7.5-alpha ). These alpha versions are used in deprecation warnings and documentation. They may even be unofficially packaged by different sites.
- a critical bug is discovered and a hotfix release needs to be created by patching 4.7.0 (without including any of the other non-critical changes present in 4.7.5-alpha...). The problem is how should we call this hotfix version?:
- A strong argument is to call it 4.7.1, to indicate that it does not contain the changes of , e.g., 4.7.5-alpha
- But the sorting would be 4.7.1 > 4.7.1-alpha and this is misleading since 4.7.1-alpha may contain changes not present in 4.7.1
This reflects an incompatibility between semver and this kind of hotfix releases.
proposed solution
Adhere to python versioning (PEP440) instead of semver in taurus. PEP440 allows an arbitrary number of dot-separated integers in its release segment, allowing us to use, e.g. 4.7.0.1 for a hotfix on 4.7.0
In this way, we would have the following sorting:
4.7.0-alpha (normalized to 4.7.0a0) < 4.7.0 < 4.7.0.1 < 4.7.1-alpha (normalized to 4.7.1a0) < 4.7.5a1
possible implementations
Implementing the above proposed solution does not strictly require any config or code changes, just agreeing and documenting it.
In such case, releasing a hotfix would require manual version bumping (i.e., not using bumpversion) for that hotfix release
But, IMHO it may be worth to use this opportunity to change the bumpversion configuration in order to directly use normalized PEP440 versions instead of using "-alpha" and relying on python normalization of the versions. This should be as easy as using this configuration for bumpversion.
This would have the added benefit of being better aligned to do dev releases in pip and conda-forge (see e.g. https://github.com/conda-forge/sardana-feedstock/issues/1)