[Distutils] Common version-comparison semantics for peace love and harmony

Tarek Ziadé ziade.tarek at gmail.com
Sat Nov 28 17:07:01 CET 2009


On Sat, Nov 28, 2009 at 12:28 PM, Floris Bruynooghe
<floris.bruynooghe at gmail.com> wrote:
> On Fri, Nov 27, 2009 at 10:00:22PM -0500, P.J. Eby wrote:
>> This is why I've argued for keeping a scheme in 386 that can
>> mechanically translate most existing versioning schemes found in the
>> wild: it means that most people won't have to do a thing, as tool
>> builders can just use suggest_version().
>
>
> This is an important point.  I tought the aim of PEP 386 was to create
> a version scheme that can represent every version number developers
> want to express, not to create one that allows everyones favourite
> syntax.
>

Absolutely,

"suggest_rational_version" is just here to allow package managers
softwares to handle existing versions, and eventually raise a warning
when they get those.


> And it seems most of the discussion has now ventured back into the
> syntax (flamewars/bikeshedding?) instead of whether everyone can
> express the versions they need to.

Agreed. We jumped again in the black hole :)  I don't see much
progress in the thread.

Fact 0: This PEP is important for interoperability

Fact 1:
We do need to express development versions, post/pre release versions
and we do want to have a standard to be shared among public python
package installers.

Fact 2:
there are many ways to express those markers, but the PEP will
document *one* way and promote its usage, so public package installers
are all *compatible* (distutils, pip, etc..)

Fact3:
suggest_rational_ version will offer a tool for installers to deal
with more version schemes, and it is suggested that it warns the
developer that the scheme is not
PEP 386 compliant.

So If the current proposal works for all cases (e.g. people can
translate their schemes
into PEP 386 one), I am proposing to:

1- reject the "+", " ", "-" proposal, and stick with "." so we have
only one way to express the segments. (ala Python itself)

2 - keep the aliases (alpha/beta/rc) because they are not controversial

3 - stick with "post" "dev" for the post and pre-release tags because
*we need them to sort development versions and post versions* in
installers, and because *they don't hurt* for people that are not
publishing such versions. They will be able to use their own dev
markers internally if they want.

Next, once the PEP is edited, I am proposing to move this discussion
in python-dev,
for another round, and eventually have Guido accept it or reject it
and move forward with PEP 345.

Because as far as I am concerned, even if we change the syntax in PEP
386 a million times, some people will not like it at the end.

regards
Tarek


More information about the Distutils-SIG mailing list