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

[Tarek Ziadé]

On Sat, Nov 28, 2009 at 12:32 AM, Ben Finney <ben+python at benfinney.id.au> wrote:
[..]
>> the problem we have is to be able to sort those post and pre releases
>> with other versions. And this is not possible with a simple
>> alphanumerical comparison.
>
> It is, if the version strings are chosen to fit within such a comparison
> semantic.

So how do you sort development version and post-release versions
in a "simple" alphanumeric order ?

>
>> And this is not a special use case, and has to be part imho of our
>> version-comparison semantics.
>> otherwise, our scheme would be useless for developers that work as a
>> daily basis with snapshots,
>> dev versions etc.
>
> This is a red herring, AFAICT. It's been discussed already that workflow
> is orthogonal to version comparison semantics. That is, nothing about a
> workflow involving snapshots or dev versions etc. implies that
> exceptional version keywords need to be accommodated. Exactly the same
> workflow can take place by choosing different version strings that work
> with existing version-comparison semantics.

I don't understand what you mean by workflow. When you need to compare versions,
wether they are development versions, or pre and post-release
versions, or final version,
you need to sort them.

>
> Moreover, AIUI there is no injunction that all projects must follow
> exactly the semantics of PEP 386, right? So why not have a *simple*
> standard (all version string components compared alphanumerically) in
> PEP 386, that is known to work unmodified with existing package systems,
> without Python-specific translation layers for version comparison?

A project process is not a private thing. If you use third party
libraries, you hit the problem
of having to install development versions or pre-release versions.

Tarek.