[Distutils] PEP 426, round 733 ;)

[Philippe Ombredanne]

On Mon, Feb 4, 2013 at 2:10 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> As usual, PEP inline below and on the web at
> http://www.python.org/dev/peps/pep-0426/
> Version scheme
> ==============
> Version numbers must comply with the following scheme::
>     N.N[.N]+[{a|b|c|rc}N][.postN][.devN]
>
> Version numbers which do not comply with this scheme are an error. Projects
> which wish to use non-compliant version numbers must restrict themselves
> to metadata v1.1 (PEP 314) or earlier, as those versions do not mandate
> a particular versioning scheme.
>
> Suffixes and ordering
> ---------------------
> The following suffixes are the only ones allowed at the given level of the
> version hierarchy and they are ordered as listed.
> Within a numeric release (``1.0``, ``2.7.3``)::
>    .devN, aN, bN, cN, rcN, <no suffix>, .postN

Are we trying to mix in too many thing in a versioning scheme?

IMHO a version (or eventually its dot-separated segments with
precedence from left to right) should increase when sorted
lexicographically so it is never ambiguous for a human reading a list
of versioned components, sorts naturally in most filesystems and tools
and is easy to implement.
With the proposed scheme, I can picture myself having to call some
code each time I need compare two package versions and scratching my
head otherwise.
Having been involved in defining version schemes in the past for
Eclipse, I came then to the conclusion that anything that does not
sort lexicographically is probably a bad idea.


Are we trying to make a version -- which is an engineering must --
into something that  has also some semantics about the level of
completion of a project or some "marketing" alert on the level of
maturity of a software release? Could we stay instead in the realm of
engineering?

I think that trying to inject things like alpha, beta, post,  dev,
release candidates and the likes in this is trying to bake in too many
things that are eventually just the practices of some  projects and
should not be the frozen practice baked in a PEP.  Instead, this
should be left to project authors to define their own scheme as long
as it sorts lexicographically (eventually by segments, with precedence
from left to right).

-- 
Philippe Ombredanne

+1 650 799 0949 | pombredanne at nexB.com
DejaCode Enterprise at http://www.dejacode.com
nexB Inc. at http://www.nexb.com