[Distutils] PEP 426, round 733 ;)

[Ronald Oussoren]

On 4 Feb, 2013, at 17:00, a.cavallo at cavallinux.eu wrote:

> I agree *completely* with Philippe here.
> 
> If a version standard will be enforced what's the point of making it more
> complicated that a sequential number or something along x.y.z? In the end that's
> what the version number is.

Because the version number is just more complicated? The details have been
discussed at length (and then some more) on this list, but just consider the common
scheme of alpha, beta and release-candidate releases. 

Without special support you'd end up with a version 1.0 being older than 1.0rc1.

Ronald

> 
> 
> 
> 
> On Mon 04/02/13 16:31, "Philippe Ombredanne" pombredanne at nexb.com wrote:
>> On Mon, Feb 4, 2013 at 2:10 PM, Nick Coghlan <ncoghlan at g
>> mail.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
> 
>> 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
> ....
>> 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 n
>> exB.com
> DejaCode Enterprise at http://www.dejacode.com
> nexB Inc. at http://www.nexb.com
> _______________________________________________
>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>> http://mail.python.org/mailman/listinfo/distutils-sig
>> 
>> 
> 
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig