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

[P.J. Eby]

At 12:26 PM 11/28/2009 +1100, Ben Finney wrote:
>I think you're reading a proposal that I didn't write.

Are you not the person who's proposed using simple alphanumeric 
strings for version comparison?

>My understanding of PEP 386 is that it *isn't* about asking Python 
>developers to change how they work. Is that not right?

Asking them to generate alternative versioning schemes, without the 
ability to use pre-release versions (e.g. alpha, beta, etc.) would 
most certainly be a change from the status quo.

>  Moreover, what is a standard for if not for encouraging people to 
> follow it for the benefit of many?

Usually, they get something in trade.  Supporting WSGI means you get 
to use WSGI apps, or run on a WSGI server, for example.  So, cost and 
benefit are balanced.

In contrast, a popular Python library or app will get packaged if 
somebody wants it, and not if they don't.  There isn't a lot of 
incentive for a developer to do something different, solely for the 
sake of the packager...  which is probably why things are the way they are now.

If, on the other hand, there's some positive benefit being offered 
(e.g. a new tool that makes life easier for them or perhaps their 
users), then there might be some incentive to learn a new way of 
coding versions.  But without such an incentive, who wants to learn 
some new way to encode prerelease versions?

This is why I've argued for keeping a scheme in 386 that can 
mechanically translate most existing versioning schemes found in the 
wild: it means that most people won't have to do a thing, as tool 
builders can just use suggest_version().