1.8 KiB
Semantic Versioning
NOTE: Support for
setuptools_scm
is currently removed due to a known issue with the way pip installations restrict access to certain SCM metadata during package installation. Support will be restored whensetuptools_scm
andpip
developers fix this with a patch.
This library is configured to use setuptools_scm to automatically get package version from git commit histories.
There shouldn't be any references to manually coded versions.
Verify what git tag to use by running:
python setup.py --version
It should look something like 0.1.0.dev4+gdfedba7.d20190209
Using the information above the master branch, after a merge commit, can be Tagged with the above semantic version 0.1.0
(ignoring the dev4+gdfedba7.d20190209
)
For example:
git tag v0.1.0
Now verify the semantic version for the package:
python setup.py --version
All new merged commit on master must have a Semantic Versioning release version with an accompanying tag. TL;DR:
major.minor.patch
- Patch is for bugfix
- Minor is for new features
- Major is for backwards-incompatible changes
- tags should be of the form
v0.1.2
Installing this library into another clean git repository with a tag version, you should get a nice version like 0.2.1
.
However, if you inspect the __version__
in this repo,
you'll get a nice 'dirty' version number like '0.2.1.dev0+g850a76d.d20180908'
.
This is useful for debugging, building sphinx docs in dev and so on.
You should never have to specify a version manually except just tagging your commit from the tag calculation generated by running
python setup.py --version