[Distutils] PEP 440 and prefix matching

[Nick Coghlan]

On 28 June 2013 00:15, Donald Stufft <donald at stufft.io> wrote:
>
> On Jun 27, 2013, at 7:24 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> It occurs to me, though, given that we now have an exact prefix
>> matching notation for more unusual forward compatibility constraints,
>> we *could* just make all compatible release clauses explicitly
>> semantic versioning based. Then you could say things like (2.2.2) or
>> (~= 2.2.2) to mean (>= 2.2.2, == 2.*). Under the current PEP, those
>> clauses would translate to (>= 2.2.2, == 2.2.*), which differs for no
>> good reason I can see from the handling of a clause like (~=
>> 2.2.post1), which would translate as (>= 2.2.post1, == 2.*).
>>
>> I think the semantic versioning based system is actually easier to
>> explain than the current scheme (mostly because it's more consistent),
>> so unless someone comes up with a compelling counterargument in the
>> next few days, I'll switch the specification to always use "== V.*" as
>> the prefix matching component of a compatible release clause, no
>> *matter* how many components there are in the version specifier
>> itself.
>
> No don't do that. Not everything follows semver like that. For instance Django
> often times needs changes between a 1.N and a 1.N+1, but 1.N.* is supposed
> to be as backwards compatible as possible to make it simple for people to
> get security updates. Forcing it to always be N.* feels way to opinionated for
> something like versioning across all of the Python ecosystem.

I think that counts as a compelling counterargument - I guess I'm
leaving the PEP alone on that front, then :)

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia