Range of values ​​in gradle

Question

What are the possible ways to specify version ranges in gradle dependencies? I saw note 1. +, but I did not find a document that really says what is possible and what is not. Also, I don't know if Maven ranges can be used.

Can someone give me a quick overview so that I can understand the rules?

Answer 1

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

[1.0,2.0] [1.0,2.0[ 

and

 [1.0, ) 

for all versions starting from 1.0.

Answer 2

Preferred alternative : specify version range using ivy notation. Here are some examples copied from this web page :

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

A difficult alternative : use the “+” in a major, minor, or patch number. This approach has at least two problems:

• If you create a library and generate a pom file, pom will not be compatible with maven unless you use some workaround to determine the version and prevent pom from using "+" in the version element. See this issue of Grad GitHub .
• The value "+" is subject to confusion. Well, maybe not, but ask everyone if all your peers know the difference between 1.1.+ And 1.1+ depending on gradle.

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

• In the old days, backward compatibility was sacred. This is no longer true. Newer versions often move / delete / rename classes and functions.
• If your dependency is dynamic (especially with a "+" or unrelated range), a new version may be selected at the next build that is incompatible with your project. Incompatibility can only be detected in rutime.
• Version X of your library created today may be different from version X of your library created tomorrow if one of its dependencies is dynamic and a new production is released overnight. This level of uncertainty is undesirable for libraries.