FYI semver 2.0.0 final was released :-) semver.org
On Thu, Jun 27, 2013 at 7:24 AM, Nick Coghlan <[email protected]> wrote: > On 27 June 2013 19:16, Vinay Sajip <[email protected]> wrote: >> All the examples of explicit prefix matching in PEP 440 show only release >> clause components, but it's not explicitly stated whether that's >> specifically intended. For example, are prefix matching clauses such as >> >> == 1.2.dev0.* >> != 1.2.post1.* >> >> allowed? > > Sure. I'm not sure why anyone would actually want to do it, but it's > allowed (disallowing it would actually make the spec more complicated > rather than simpler). > > The only thing which explicitly ignores the suffix is the compatible > release clause: "If a pre-release, post-release or developmental > release is named in a compatible release clause as V.N.suffix, then > the suffix is ignored when determining the required prefix match" > > The rationale for that restriction is that we're mostly using the same > compatible release semantics as semantic versioning, except that we > assume a reasonable level of backwards compatibility will exist even > for 0.x releases, leaving it to people to use prefix matching if a > dependency exposes a somewhat unstable API. Semver doesn't define > compatibility semantics outside the release number, so we don't > either. > > 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. > > Cheers, > Nick. > > -- > Nick Coghlan | [email protected] | Brisbane, Australia > _______________________________________________ > Distutils-SIG maillist - [email protected] > http://mail.python.org/mailman/listinfo/distutils-sig _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
