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 when setuptools_scm and pip 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