[Distutils] Comparison semantics for alphanumeric components of a version number (was: Version comparison - round 2)

[Paul Moore]

2009/6/5 Ben Finney <ben+python at benfinney.id.au>:
> Tarek Ziadé <ziade.tarek at gmail.com> writes:
>
>>   http://bitbucket.org/tarek/distutilsversion/src/tip/README.txt
>>
>> The goal here is to provide a version comparison standard to be
>> included in Distutils.
>
> I laud this goal, and thank you for soliciting feedback on this draft.
>
> One thing I haven't seen discussed: Why have such baroque version
> comparison semantics been accepted? Surely one of the overarching goals
> for such a standard is that it be simple to comprehend, and to behave
> unsurprisingly to most users.
>
> Yet the discussion around these non-obvious semantics, trying to have
> components interpreted as “pre-release” and “post-release” and
> “development release” and so on seem to underline the fact that
> they're *not* something that there's any consensus on. So why are they
> being foisted into a standard for version strings?
>
> Rather than trying to force non-alphanumeric comparison semantics for
> alphabetic sequences, why not simply say that alphanumeric comparison
> semantics apply for components? That would, at a stroke, end all this
> turmoil and IMO futile seeking of some other consensus, when the best
> consensus is already what most would expect: alphanumeric comparison.
>
> At the least, I would expect there would need to be a demonstrated,
> significantly unified consensus for some specific *other* semantic
> before discarding straightforward alphanumeric comparison as the
> standard.

+1. The historical baggage of setuptools (which *had* to cater for
every bizarre convention currently in existence, as its goal was to
"embrace and extend" - something it achieved spectacularly) doesn't
seem to apply when creating a standard Python module.

I'd rather the PEP said "This is how version numbers work (simple,
non-controversial spec here), and this is the standard API for
manipulating them", and then projects that want to conform to the
standard migrate if needed.

But I acknowledge that I have no personal requirement for any of this,
so the only interest I have is an aesthetic one of *not* seeing
overcomplicated, difficult to understand, specifications become part
of the Python stdlib.

Paul.