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

[Tarek Ziadé]

On Sat, Nov 28, 2009 at 4:00 AM, P.J. Eby <pje at telecommunity.com> wrote:
> 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().

Yes, this function can be used internally,  and that was a good idea
to have that function.

But as soon as it is used inside a public package manager, like pip or
setuptools or distribute, I expect this function to raise some kind of
warning so the developers knows its version
doesn't meet the public, documented standard.