On Tue, Feb 5, 2013 at 7:54 AM, Donald Stufft <donald.stufft@gmail.com> wrote:
On Tuesday, February 5, 2013 at 5:35 AM, a.cavallo@cavallinux.eu wrote:
Ideally it would be something that connects to the source revision number (as in
subversion) or the integral id or even a timestamp (that's what an exported
version must be).
Timestamp or reversion number is not overall useful number for a version and
here's why: Django (for example) maintains older versions for a set period of time,
If you do it via timestamps than 1.1.1 which happens to be released after 1.2.0 (because
of a security issue or glaring bug) will be considered "newer". Handwaving the problem
away with a source revision number or timestamp ignores a fundamental property
of a version

What pkg_resources does for sorting is to append "final" for sorting. So the sorting is really just a, b, c, f. This scheme has been important for 8+ years now. PEP 386, from 2009, narrows the allowed versions. Now the salient part of PEP 386 has been incorporated into Metadata 1.3.

1.0.0a0
1.0.0b0
1.0.0c0 ~= 1.0.0rc0
1.0.0 == 1.0.0f

The "marketing pre-release" feature exists to allow publishers to put immature versions of their software on pypi where they can be easily downloaded. Recently SQLAlchemy did this but had to delete the beta release from pypi because too many deployments upgraded to an unstable version without realizing it. Once the tools are updated it will be easy to install a beta release with pip if and only if you specifically ask for it.

What if we replaced this with semver? Last fall I argued that PEP 386 sucked and that we should use semver. Unfortunately semver is less similar to the longstanding sort order than the proposed scheme, there would be a lot of - and + in the version numbers, and package tools would be more likely to have to implement both PEP 386 and semver to work properly. It would result in a minimal amount of win. I can live with the PEP 386 style version numbers and will stick to using Major.Minor.Micro for my projects.