The attached patch only allows snapshot versions to be contained in a range if they are equal to one of the boundaries. Note that this is a strict equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT.

If you are making cross-cutting changes across multiple projects, you might want to temporarily allow snapshots locally. Likewise, if you load two dependent projects into an IDE, you typically want one of them to resolve to the other, which effectively means resolving to a snapshot.
What I am missing is simply a command-line switch that would globally allow or disallow resolution of version ranges to snapshots. That'd have eliminated most of the workarounds that we had to implement.

Sergei Ivanov
added a comment - 04/Aug/14 5:14 PM If you are making cross-cutting changes across multiple projects, you might want to temporarily allow snapshots locally. Likewise, if you load two dependent projects into an IDE, you typically want one of them to resolve to the other, which effectively means resolving to a snapshot.
What I am missing is simply a command-line switch that would globally allow or disallow resolution of version ranges to snapshots. That'd have eliminated most of the workarounds that we had to implement.

@Richard, I don't want to troll but you've said a lot here from your own perspective, which while entirely valid for your own flavour of version ranges, simply does not work for the semantic versioning most people were implementing before this mess began.

The way it used to work was specified - supporting semantic versioning without any tricks, purging, double repos or otherwise.

I agree with you completely on changing the specification, at an absolute minimum consistency should be maintained.

Caspar MacRae
added a comment - 04/Aug/14 5:24 PM @Richard, I don't want to troll but you've said a lot here from your own perspective, which while entirely valid for your own flavour of version ranges, simply does not work for the semantic versioning most people were implementing before this mess began.
The way it used to work was specified - supporting semantic versioning without any tricks, purging, double repos or otherwise.
I agree with you completely on changing the specification, at an absolute minimum consistency should be maintained.
http://semver.org/
http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf

Yes @Sergei, however you are releasing that snapshot are you not? If we manage to get this plugin working then it would solve your problem as well, but I certainly wouldn't recommend doing so.

@Casper - I am just one person speaking up about this. Thats what the argument was - too many people rely on the functionality as it is right now, if you change it, you'll break all these and then they'll come complaining on this ticket and we'll get the reverse.

Richard Vowles
added a comment - 04/Aug/14 5:28 PM Yes @Sergei, however you are releasing that snapshot are you not? If we manage to get this plugin working then it would solve your problem as well, but I certainly wouldn't recommend doing so.
@Casper - I am just one person speaking up about this. Thats what the argument was - too many people rely on the functionality as it is right now, if you change it, you'll break all these and then they'll come complaining on this ticket and we'll get the reverse.

Well, at the moment releasing a large cross-cutting change requires some self-discipline, because Maven is not really helping us there. The only safeguard we have is a release CI build that will reject any incompatible changes that rely on the latest snapshots. But working with snapshots locally is often the only way to test a large change before slowly committing the changes in the dependency order and feeding them into the release process.

Sergei Ivanov
added a comment - 04/Aug/14 5:49 PM Well, at the moment releasing a large cross-cutting change requires some self-discipline, because Maven is not really helping us there. The only safeguard we have is a release CI build that will reject any incompatible changes that rely on the latest snapshots. But working with snapshots locally is often the only way to test a large change before slowly committing the changes in the dependency order and feeding them into the release process.

So I think we need to add documentation to "http://maven.apache.org/pom.html". Right now, it has a section on dependencies stating:

groupId, artifactId, version:
These elements are self-explanatory

I think this is the root of all the pain and frustration in this thread. It's incredibly frustrating and upsetting that this huge issue was being dismissed as "self-explanatory" in the docs the whole time.

I would be willing to spend time to work and collaborate on improving the documentation.
Does anyone know who can be contacted to change http://maven.apache.org/pom.html ?

Jon Harper
added a comment - 05/Feb/15 10:31 AM Hi,
I'm new to this discussion. A first objective is to get the documentation to match the implementation.
The link ( http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution ) in the original description of this issue seems to be the only documentation of version ranges. But it is not documentation, it's a design document. People are turning to it because the real documentation is missing. I think that if we fix the real documentation, it will prevent more confusion.
So I think we need to add documentation to "http://maven.apache.org/pom.html". Right now, it has a section on dependencies stating:
groupId, artifactId, version:
These elements are self-explanatory
I think this is the root of all the pain and frustration in this thread . It's incredibly frustrating and upsetting that this huge issue was being dismissed as "self-explanatory" in the docs the whole time.
I would be willing to spend time to work and collaborate on improving the documentation.
Does anyone know who can be contacted to change http://maven.apache.org/pom.html ?