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

[Tarek Ziadé]

On Sat, Nov 28, 2009 at 10:05 PM, P.J. Eby <pje at telecommunity.com> wrote:
> At 09:41 AM 11/28/2009 +0100, Tarek Ziadé wrote:
>>
>> That's completely wrong, the proposal is a benefit for all of us,
>> because it standardizes something that is already being done.
>
> You seem to have misunderstood me; I'm objecting to Ben Finney's "simple
> alphanumeric sort", not to PEP 386 in general.

Ok,

>
>
>> PEP 386 propose a scheme to be adopted by developers or tools, but if some
>> people want to stick with their own internal version scheme for
>> development versions or post/pre release versions, they can do it
>> without any problem. And they don't have to follow
>> any PEP 386 convention for their internal work.
>
> This is not actually true, since developers working in a team situation can
> be sharing and building binary releases of these packages.

As long as they are using and sharing their own tool that respect
their specific version scheme,
where they have a classical scheme for final releases, and a specific
scheme for development releases, how would that be a problem if they
don't publish at PyPI or to others those specific versions ?


>> So you have two choices:
>> - an implicit, heuristic ordering (that's what is happening today)
>> - a explicit, documented ordering. that's the goal of PEP 386.
>
> Setuptools' version scheme *is* explicit and documented -- as you should
> know, since I pointed you to those docs when you were writing PEP 386.

Sorry I was unclear. Implicit was the wrong word. What I wanted to say is that
setuptools will order any version string a project provides without complaining,

IOW, 'Foo' and 'Bar' are valid version numbers with it.

So you have two choices:
 - an loose version scheme, where any string can be a version and will
be compared
   (that's what is happening today)
 - a stricter version scheme, based on a segmented ordering. that's
the goal of PEP 386.


Tarek