Version ranges in gradle

Question

What are the possible ways of specifying version ranges in gradle dependencies? I saw some 1.+ notation but I have not found a document which really says what is possible and wh

Answer 1

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.