On 28 June 2013 00:15, Donald Stufft <don...@stufft.io> wrote: > > 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.
I think that counts as a compelling counterargument - I guess I'm leaving the PEP alone on that front, then :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
