[Distutils] RFC : Version comparison

[Tarek Ziadé]

2009/5/14 P.J. Eby <pje at telecommunity.com>:
> At 02:34 PM 5/13/2009 +0200, Tarek Ziadé wrote:
>>
>> Any feedback on this "dev version of post release" use case
>
> It looks like the 'suggest' function doesn't handle svn revisions properly

Ok I'll check that

> To be clear, I'm not opposed to blessing a normalized version scheme --
> there are solid benefits to doing such a thing.  I'm opposed to putting one
> in the stdlib without a clear rationale for the choices, and an upgrade path
> that either lets setuptools users ignore the new scheme, or gives them some
> benefit for switching.

PEP 345 is being rewritten with a rationale specification of versions
in mind, and the plan
is to refer to this version scheme and document it there.

see http://svn.python.org/view/peps/branches/jim-update-345/pep-0345.txt?view=markup

from a setuptools user point of view, the benefit I can see is that
they will have better
version numbers that will comply with a documented standard, that is
usable and understandable
by os packagers for example.

Now I suppose setuptools will have to propose both for some time, but
in Distutils,
no one really uses LooseVersion and StricVersion, so the idea is to
deprecated them and introduce
the new one in there.

But what I am scared of is : who will work on setuptools side ? can
you bless someone to do the
work when we agree on a common roadmap ?

>
> Meanwhile, I haven't seen any indication that this new format is easier for
> non-Python tools to parse.  Is the plan for other tools to use the stdlib
> parsing code, because I don't see how existing tools like RPM et al could
> use the proposed scheme.

Some people from Fedora and Ubuntu worked on this (I've CC them) , and
the whole idea was to provide
a scheme that would make rpm and debian packagers happy with it.

I am not a RPM expert at all, but the output is supposed to be
RPM-friendly. Toshio ?

Regards
Tarek

-- 
Tarek Ziadé | http://ziade.org