Skip to content
This repository has been archived by the owner on Nov 16, 2023. It is now read-only.

Latest commit

 

History

History
46 lines (29 loc) · 1.78 KB

VERSIONING.md

File metadata and controls

46 lines (29 loc) · 1.78 KB
Raw

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