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? Regards, Vinay Sajip
On 27 June 2013 19:16, Vinay Sajip
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 | ncoghlan@gmail.com | Brisbane, Australia
FYI semver 2.0.0 final was released :-) semver.org
On Thu, Jun 27, 2013 at 7:24 AM, Nick Coghlan
On 27 June 2013 19:16, Vinay Sajip
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 | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
On Jun 27, 2013, at 7:24 AM, Nick Coghlan
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
On 28 June 2013 00:15, Donald Stufft
On Jun 27, 2013, at 7:24 AM, Nick Coghlan
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@gmail.com | Brisbane, Australia
participants (4)
-
Daniel Holth
-
Donald Stufft
-
Nick Coghlan
-
Vinay Sajip