On Tue, Feb 5, 2013 at 7:54 AM, Donald Stufft 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.

On Tue, Feb 5, 2013 at 3:08 PM, Daniel Holth wrote:

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.

May be versioning scheme is trying to take on too much on itself that could possibly be solved elsewhere in a simpler way? Immature software distribution is a requirement that makes perfect sense --but even that is not in the scope of this PEP -- could it better addressed by having a something like Pypi "release channels" instead .... ie some separate indexes for unstable/alpha/bleeding edge packages that responsible and consenting adults could use as they please or something similar? This is FWIW a common practice on Debian. -- Philippe Ombredanne +1 650 799 0949 | pombredanne@nexB.com DejaCode Enterprise at http://www.dejacode.com nexB Inc. at http://www.nexb.com

On Tue, Feb 5, 2013 at 9:08 AM, Daniel Holth wrote:

On Tue, Feb 5, 2013 at 7:54 AM, Donald Stufft 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.

Yes, this is incredibly useful and I'm glad it was incorporated into this PEP. For the Astropy project for example we recently release version 0.2b2 and we absolutely want to be able to put it on PyPI for users to test out. But as the current situation stands we can't do that because 0.2b2 then becomes the "latest" version, and the one the gets installed when users expecting the latest stable release do `pip install astropy`. So instead we've just been adding the pre-final release to testpypi and pointing people there. And that's not really meant to be a reliable service. So...yeah. A++ for adding this requirement.