[Distutils] PEP 440 and prefix matching

[Donald Stufft]

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.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130627/fdab31f1/attachment.pgp>