(This is a subset of the larger dependency management issues discussed in GRADLE-646)

An useful subset of the larger dependency management problem with version ranges is the idea of pinning a dependency down to a specific version. The syntax would look like this:

group: 'net.twasink', name: 'myartifact', version: '[1.0]'

This syntax has the advantage of being compatible with both Ivy and Maven.

Using pinned versions are a very convenient way of dealing with transitive dependencies that bring in newer undesired versions. This can be done manually - using the 'failOnConflict' approach from GRADLE-1899 to detect the conflicts, and then setting up exclusion rules - but that can be a time consuming process, especially for common 3rd-party libraries (e.g. differing, but compatible, versions of commons-lang). It also produces a lot of verbosity. By using this subset of version range matchers, a very common use case ('use exactly this version of that library') is solved. I have a vested interest in this as I have a large set of Maven-based projects that I would love to convert to Gradle, but which use pinned versions for exactly this task.

(Naturally, if the same dependency has multiple pinned versions in the tree, then a conflict would occur)

I've developed a bunch of Cucumber tests to drive Gradle and compare its behaviour to Maven. These tests are available at https://github.com/twasink/GradleDependencyTests - see https://github.com/twasink/GradleDependencyTests/blob/master/features/pinned_dependencies.feature in particular.

The result of the tests (against current Gradle head) is at http://twasink.net/files/gradle_dependency_result_2011_12_09.html