Simplify version numbering

[pjz]

I was going to build a wheel, but...

$python2 setup.py
/usr/local/lib/python2.7/dist-packages/setuptools/dist.py:294: User
arning: The version specified (u'0.7.0~pre0.98.g3e598c2') 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.
  "details." % self.metadata.version
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ..
]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: no commands supplied

[SebKuzminsky]

Hi @pjz, the current version numbers are designed to work well as debian package version numbers. I didn't mean to break them for setup.py in the process, but clearly I did...

My goals for the version number are:

• make version numbers that make sense both on "official" branches (master, stable/*) and on short-lived feature branches
• make version numbers be as nicely human-readable as possible
• have the version number unambiguously identify the git commit that it corresponds to

I wonder if we can come up with something that makes both dpkg and setup.py happy.

PEP 440 Debian package version numbers

[sumpfralle]

Since pycam uses the python packaging tools, I guess we should use a primary version scheme compatible with these (here: PEP440). Thus we should indeed remove the tilde from the snapshot versions.

For the deb package version number we will probably need to reformat this version number (which is acceptable according to the Debian Policy).

How about this one?

• pycam version: 0.7.0.dev0.98.g3e598c2
• deb package version: 0.7.0~pre0.98.g3e598c2

This would require:

• change the "pre-release" tag from v0.7.0-pre0 to v0.7.0.dev0
• change the version substitution in pycam/__init__.py from re.sub('-pre([0-9])', r'~pre\1', git_describe, 1) to re.sub('\.dev([0-9]+)', r'~pre\1', git_describe, 1)

This approach would allow proper sorting both for python package tools as well as Debian package tools.

[SebKuzminsky]

That seems like it would work.

I would prefer it if the string in all three places "looked" the same, ie using either "dev" or "pre" everywhere.

I have a slight preference for "pre" over "dev", because to me "pre" seems unambiguously "before", whereas "dev" could be before or after.

So I'm proposing this:

• pre-release tag: "v0.7.0.pre0"
• python setup version "v0.7.0.pre0.98.g3e598c2"
• dpkg version: "v0.7.0~pre0.98.g3e598c2"

[sumpfralle]

Yes, I would also prefer identical or at least similar version strings.

Thus, I took another look at PEP440:

• indeed pre is an allowed tag - indicating a release candidate (synonym for r or rc)
• non-digits (e.g. for the commit hash) are only allowed for Local version identifiers

Thus I would propose the following for a PEP440-compliant version string:

• pre-release tag: v0.7.0-pre0
• project version: v0.7.0-pre0+98.g3e598c2
• deb package version: v0.7.0~pre0+98.g3e598c2

[SebKuzminsky]

Great! I'm going to be out of town for a week, but I will work on this when I get back, if no one beats me to it 😊