Breaking change to dynamic versions + SNAPSHOTS (in Gradle 1.12!)

[Daz DeBoer]

G'day

Today we received a Pull Request to fix GRADLE-3080: the crux of this issue is that a selector like "1.+" should never match "1.1-SNAPSHOT" in a Maven repository. 

Prior to 1.12, I think this worked by accident, but only for Maven repositories where SNAPSHOT artifacts have a unique timestamped version, and a correctly formatted "maven-metadata.xml". When a Maven repository had non-unique SNAPSHOT versions, then "1.+" _would_ include SNAPSHOT artifacts.

So we should decide what behaviour we want going forward:

1. Should Gradle honour the Maven convention of _not_ including SNAPSHOT versions for a version range like "[1.0, 2.0)"? We should probably have the same behaviour for "1.+" for consistency.

2. If so, should this rule apply to _all_ repositories (Ivy, File, etc), or just to Maven repositories?

The pull request addresses this issue in a simple way via version selectors, which apply the same to all repositories.

Thoughts? What behaviour do we want Gradle to support?

--

Darrell (Daz) DeBoer

http://www.gradleware.com

[Adam Murdoch]

On 12 Dec 2014, at 6:55 am, Daz DeBoer <darrell...@gradleware.com> wrote:

G'day

Today we received a Pull Request to fix GRADLE-3080: the crux of this issue is that a selector like "1.+" should never match "1.1-SNAPSHOT" in a Maven repository. 

I don’t think “never” is quite right.

There are (at least) 2 dimensions that I need to be able to express:

- Compatibility. What’s the minimum set of features I need?

- Maturity: What’s the minimum level of quality I would accept?

The problem is we need to be able to express both of these constraints independently, for each dependency. Sometimes I want milestones, sometimes I want only releases, sometimes I want anything that has been published.

So, in some cases ‘1.+’ should accept snapshots, and some others it should not. Depends on the relationship between the consumer and publisher.

Currently, ‘+’ is a prefix match. It doesn’t do any kind of semantic matching. If we change it to exclude snapshots, then we’re adding partial filtering on maturity. But not in any consistent way. Why should it accept betas but discard snapshots?

We should either leave it unchanged, or change it to discard any kind of pre-release (ie status != release) regardless of where it came from. And if we change it to do any kind of semantic matching we should just change it into a version range.

I don’t think it’s a good idea to change its behaviour. It just does prefix matching. I would add a different convenience to replace it to do semantic matching, such as `1.2.x` or `~1.2` or `^1.2.3`

Prior to 1.12, I think this worked by accident, but only for Maven repositories where SNAPSHOT artifacts have a unique timestamped version, and a correctly formatted "maven-metadata.xml". When a Maven repository had non-unique SNAPSHOT versions, then "1.+" _would_ include SNAPSHOT artifacts.

So we should decide what behaviour we want going forward:

1. Should Gradle honour the Maven convention of _not_ including SNAPSHOT versions for a version range like "[1.0, 2.0)"? We should probably have the same behaviour for "1.+" for consistency.

2. If so, should this rule apply to _all_ repositories (Ivy, File, etc), or just to Maven repositories?

The pull request addresses this issue in a simple way via version selectors, which apply the same to all repositories.

Thoughts? What behaviour do we want Gradle to support?

I’m quite reluctant to mix maturity into version range matching, at least not without a way to express the ‘i don’t care about maturity’ case.

If we match on maturity, it has to be consistently applied to all component instances, regardless of source, and we have to treat all pre-releases the same way, regardless of naming scheme. Just matching on ‘endsWith ‘SNAPSHOT’ is out.

--

Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com

[Daz DeBoer]

On Thu, Dec 11, 2014 at 3:53 PM, Adam Murdoch <adam.m...@gradleware.com> wrote:

On 12 Dec 2014, at 6:55 am, Daz DeBoer <darrell...@gradleware.com> wrote:

G'day

Today we received a Pull Request to fix GRADLE-3080: the crux of this issue is that a selector like "1.+" should never match "1.1-SNAPSHOT" in a Maven repository. 

I don’t think “never” is quite right.

Right, I guess I meant that _Maven users_ never expect a SNAPSHOT version to be included in a version range. A bit like SNAPSHOT versions are always considered to be 'changing' in a maven repository. It _could_ be considered a semantic of the repository type, or it _could_ be considered something about the Maven resolves dependencies.

 

There are (at least) 2 dimensions that I need to be able to express:

- Compatibility. What’s the minimum set of features I need?

- Maturity: What’s the minimum level of quality I would accept?

The problem is we need to be able to express both of these constraints independently, for each dependency. Sometimes I want milestones, sometimes I want only releases, sometimes I want anything that has been published.

So, in some cases ‘1.+’ should accept snapshots, and some others it should not. Depends on the relationship between the consumer and publisher.

Currently, ‘+’ is a prefix match. It doesn’t do any kind of semantic matching. If we change it to exclude snapshots, then we’re adding partial filtering on maturity. But not in any consistent way. Why should it accept betas but discard snapshots?

We should either leave it unchanged, or change it to discard any kind of pre-release (ie status != release) regardless of where it came from. And if we change it to do any kind of semantic matching we should just change it into a version range.

I don’t think it’s a good idea to change its behaviour. It just does prefix matching. I would add a different convenience to replace it to do semantic matching, such as `1.2.x` or `~1.2` or `^1.2.3`

Prior to 1.12, I think this worked by accident, but only for Maven repositories where SNAPSHOT artifacts have a unique timestamped version, and a correctly formatted "maven-metadata.xml". When a Maven repository had non-unique SNAPSHOT versions, then "1.+" _would_ include SNAPSHOT artifacts.

So we should decide what behaviour we want going forward:

1. Should Gradle honour the Maven convention of _not_ including SNAPSHOT versions for a version range like "[1.0, 2.0)"? We should probably have the same behaviour for "1.+" for consistency.

2. If so, should this rule apply to _all_ repositories (Ivy, File, etc), or just to Maven repositories?

The pull request addresses this issue in a simple way via version selectors, which apply the same to all repositories.

Thoughts? What behaviour do we want Gradle to support?

I’m quite reluctant to mix maturity into version range matching, at least not without a way to express the ‘i don’t care about maturity’ case.

If we match on maturity, it has to be consistently applied to all component instances, regardless of source, and we have to treat all pre-releases the same way, regardless of naming scheme. Just matching on ‘endsWith ‘SNAPSHOT’ is out.

I guess my question was really about whether a) we want to do version matching "the Maven way" for Maven repositories, and b) whether we care about a regression introduced in 1.12.

My feeling is that the answer to both questions is no. But your outline of a better future where we can match versions based on a richer model of component maturity makes this clear.

I'm going to close the PR and reference the contributor to this discussion.

Thanks

[Henrik Pedersen]

Hi Adam and Darrell

"Currently, ‘+’ is a prefix match. It doesn’t do any kind of semantic matching"

Has this been changed so it is based upon sematic matching instead of prefix matching i newer gradle 2.6+ versions ?

If not, is it on the roadmap, and when can we expect it ?

Best regards

Henrik Pedersen

[Daz DeBoer]

On Tue, 8 Sep 2015 at 03:34 Henrik Pedersen <henr...@gmail.com> wrote:

Hi Adam and Darrell

"Currently, ‘+’ is a prefix match. It doesn’t do any kind of semantic matching"

Has this been changed so it is based upon sematic matching instead of prefix matching i newer gradle 2.6+ versions ?

If not, is it on the roadmap, and when can we expect it ?

No, we're not planning to make this change, for the reasons outlined by Adam in his email. Primarily this comes down to backward compatibility.

Adding a new version range syntax that is evaluate semantically is something we'd be interested in. However, it's not on our current roadmap.

Daz

--
You received this message because you are subscribed to the Google Groups "gradle-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gradle-dev+...@googlegroups.com.
To post to this group, send email to gradl...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gradle-dev/27c0e0a2-8f1c-4715-9f0c-cf05c9578736%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.