[Distutils] PEP 426, round 733 ;)

[Daniel Holth]

On Mon, Feb 4, 2013 at 10:31 AM, Philippe Ombredanne
<pombredanne at nexb.com>wrote:

> 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)


It's weird, but we need to maintain sort order with
https://bitbucket.org/tarek/distribute/src/tip/pkg_resources.py?at=default#cl-1948for
the subset of version numbers that fit the new regex. This issue has
been discussed at length.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130204/51de089e/attachment.html>