[Distutils] A tale of two conventions: Incompatibility of version comparison semantics

[Jean-Paul Calderone]

On Mon, 15 Jun 2009 23:08:33 +1000, Ben Finney <ben+python at benfinney.id.au> wrote:
>Floris Bruynooghe <floris.bruynooghe at gmail.com> writes:
>
>> On Mon, Jun 15, 2009 at 08:10:05PM +1000, Ben Finney wrote:
>> > Well then, I don't see a way forward on the issue of helping
>> > distributors to manage version numbers sanely. I don't know of any
>> > operating system package manager that returns different comparison
>> > results depending on what specific letters are used in the version
>> > string.
>>
>> Alpha, beta and release candidate releases have been around for ages
>> and I imagine most distributors have figured out a way of coping with
>> this.
>
>That doesn't answer the point raised, though. Isn't a major reason for
>all this work to help the downstream distributors to help migrate *away*
>from munging version strings and toward version strings that compare
>sanely as-is?
>
>> In Debian's case 1.0a1 would become 1.0~a1 for example (IIRC), which
>> sorts before 1.0.
>
>That's exactly the sort of hack I would hope would no longer be
>necessary for version strings formed under an improved version
>comparison specification.
>
>Forgive me for saying so, but this looks strongly like abandoning the
>criterion of “make it easier for distributors than it is at present”.

By having this standard, distributors do have an easier time.  They can
transform these version numbers automatically, just as they do many other
things to upstream packages automatically to turn them into a distro
package.

So no, the goal of making it easier for distributors is not being
abandoned.

Jean-Paul