Make version number PEP 440 complaint

[njh]

I am getting warnings when I run python setup.py with Python 2.7.13:

/usr/local/lib/python2.7/site-packages/setuptools/dist.py:341: UserWarning: The version specified ('0.6-svn') is an invalid version, this may not work as expected with newer versions of setuptools, pip, and PyPI. Please see PEP 440 for more details.

What is the best solution to this for pycam?

• Change the version string to 0.6.0-dev
• Change the version string to 0.6.0-alpha
• Set the version number dynamically from git hash

[SebKuzminsky]

I propose we handle the version number like LinuxCNC does:

Official releases get tagged with their official version number, like the "v0.5.1" tag we have on commit 5223de4.

Official builds are identified by a version number identical to the official version number tag.

Interim builds get their version number auto-generated using 'git describe', which produces a string like "v0.5.1-305-g99415b2". That's the most recent tag, followed by the number of commits since then, followed by the SHA of the HEAD commit. That version number has the nice features that it's fairly human readable, sorts well, and also unambiguously identifies the exact commit in the git repo that the software was built from.

This works great on master but it gets a little hairier if we're building on other branches, for example an exprerimental feature branch or bugfix branch, or a stable release branch.

In LinuxCNC we handle long-lived stable branches and temporary feature/bugfix/experiment branches differently. Temporary branches get the branch name included in the version number, and long-lived stable release branches do not, they look a lot like master, but with version tags restricted to belonging to the version of that branch. For example, we have a branch for LinuxCNC 2.7, and the tags in that branch look like "2.7.0", "2.7.1", etc.

Oh, and if you have uncommitted changes in your working tree when you build, we append "-dirty" to the version string.

The build system updates the version string in the software and in the debian package at the beginning of each build.

I think it works pretty well there, and I think it would work well here too.

[njh]

Sounds promising - but will require a bit more work than just setting it to 0.6.1-dev.

Is there some code that we can steal from LinuxCNC?

[sumpfralle]

I like bumpversion, which is suitable for updating one or more files containing version information (bumpversion is packaged within Debian). It would be useful for Makefile targets like release-major/minor/patch. (I could add this)

I am not sure, how this could be handled properly for automated snapshot builds. I think, we should not change files tracked via our version control with automated tools (even though we would discard these changes afterwards). At least the Debian packaging tools (here: dpkg-source) would complain about such a state, I think. But maybe this is just a common approach. Some examples taken from other projects would be great!

[ebo]

We should probably try to keep this as pythonic conformant as possible. Remember that there are also nightly builds as well as hardware dependencies (amd64, s86, arm...). There are also Epoc versioning (eg: PyCAM-20170227 or 2017.2.27). With any luck we can test around all that. As for post release revisions there is 0.5.1-r123 which is allowed.

[SebKuzminsky]

I propose PR #31. It makes pycam.VERSION and the version of the debian package be automatically generated by "make pycam/Version.py". Sets it to the most recent "vNumber" tag, followed by the number of commits since then, followed by the git SHA of the HEAD commit. So for example:

> python -c 'import pycam; print pycam.VERSION'
0.6-118-gaad037a

This sorts in the expected way, and the version number unambiguously tells you the git commit that the software was built from.

[sumpfralle]

This was finished in #40.