Version ranges in gradle

The book "Gradle Dependency Management" states on p. 12 and 13 that, in addition to the +-notation (2.1.+ means the range from 2.1.0 inclusive to 2.2.0 exclusive) you can use the Ivy notation for open and closed intervals of the form

[1.0,2.0]
[1.0,2.0[

or also

[1.0, )

for "all versions starting from 1.0".

Preferred alternative

Specify the version range using Ivy notation. Here are some examples copied from this web page:

• [1.0, 2.0]: all versions >= 1.0 and <= 2.0
• [1.0, 2.0[: all versions >= 1.0 and < 2.0
• [1.0, ) : all versions >= 1.0 // avoid. Unbound is dangerous!

Troublesome alternative

Use '+' in the major, minor or patch number. This approach has at least two issues:

• If you're building a lib and generating a pom file, the pom will be incompatible with maven, unless you apply some workaround to resolve the version and prevent the pom dependency to use '+' in the version element. See this Gradle github issue.
• The meaning of '+' is prone to confusion. Well, maybe not, but ask around to see if all your peers know exactly the difference between 1.1.+ and 1.1+ in a gradle dependency.

Ideal alternative

Avoid dynamic dependencies (using '+' or version ranges) altogether. Instead, use a fixed version dependency and update the version often with good testing. Here's why:

• In the old days, backwards compatibility was sacred. That's not true anymore. New versions often move/remove/rename classes and functions.
• If your dependency is dynamic (especially with '+' or unbound range), the next build may pick a new version that is incompatible with your project. The incompatibility may be detected only at rutime.
• Version X of your library as built today might be different from version X of your library built tomorrow if one its dependencies is dynamic and a new version is released overnight. This level of uncertainty is not desirable for libraries.