On Jun 27, 2013, at 7:24 AM, Nick Coghlan <ncogh...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
