10aday › tools
Type a Gradle version such as 1.+, [1.0,2.0), latest.release or 1.2.3, and the versions published for that library.
You see which versions match, in plain words, and which one Gradle will resolve. The page runs a JavaScript copy of Gradle's own version code,
checked against the real Gradle classes and against real gradle runs.
+ is a text prefix, and betas count1.+ does not mean “the newest stable 1.x”. Gradle keeps every version whose text starts with 1., then takes the highest one.
Betas and release candidates are included: if 1.11-rc1 is the highest, you get it. Without the dot, 1+ also takes 10.0 and 11.2.
Ranges have their own rule: in [1.0,2.0), anything that starts with 2.0 is left out, so 2.0-rc1 is skipped (Maven would take it).
We ran Gradle 8.14.3 against a local repository for each line below:
| Declared version | Published | Gradle resolved | Why |
|---|---|---|---|
| 1.+ | 1.0, 1.9, 1.10, 2.0 | 1.10 | 10 is higher than 9: the highest text starting with “1.” wins. |
| 1.+ | 1.0, 1.1-rc1 | 1.1-rc1 | A release candidate starts with “1.” too, and it is the highest. |
| 1.+ | 1.0, 1.1, 1.2-beta1 | 1.2-beta1 | 1.2-beta1 is higher than 1.1: betas are not skipped. |
| 1+ | 1.0, 1.5, 10.0, 11.2 | 11.2 | No dot: “10.0” and “11.2” start with “1”. |
| 1.1+ | 1.1.0, 1.12.0, 1.2.0 | 1.12.0 | “1.12.0” starts with “1.1”. |
| [1.0,2.0) | 1.0, 1.5, 2.0-rc1, 2.0 | 1.5 | 2.0-rc1 starts with the excluded bound 2.0: skipped. |
| [1.0,2) | 1.0, 1.9, 2.0-beta1, 2-rc1 | 1.9 | Bound “2”: 2.0-beta1 and 2-rc1 both start with it. |
| [1.0,) | 1.0, 3.0, 3.1-alpha1 | 3.1-alpha1 | No upper bound: an alpha above 3.0 is taken. |
| ]1.0,2.0[ | 1.0, 1.1, 2.0 | 1.1 | Ivy-style brackets: ]1.0 excludes 1.0. |
| latest.release | 1.0, 1.1, 2.0-rc1 | 2.0-rc1 | In a Maven repository an RC counts as a release. |
| latest.release | 1.0, 1.1-SNAPSHOT | 1.0 | -SNAPSHOT is not a release. |
| [1.0,2.0) | 1.0, 1.0-final, 1.0-dev | 1.0 | 1.0-final and 1.0-dev are both lower than 1.0. |
| [1.0,1.1) | 1.0, 1.0.1, 1.0-sp1, 1.1-rc1 | 1.0.1 | 1.0.1 beats 1.0-sp1 (number beats word); 1.1-rc1 starts with the bound. |
| [1.5,2.0) | 1.0, 1.4 | fails | Nothing between 1.5 and 2.0: fails. |
| Write | Means | Gradle picks (from 1.0, 1.2, 1.10, 1.10.1-rc1, 2.0-rc1, 2.0, 10.0) |
|---|
The last column is computed in your browser by the same engine as the checker above.
Gradle cuts a version into parts at ., -, _ and +, and also where digits meet letters (1.0a1 = 1, 0, a, 1).
Parts are compared one by one. Numbers are compared as numbers (1.10 > 1.9). A number beats a word (1.0.1 > 1.0-beta).
A few words have a fixed rank: dev < any other word < rc < snapshot < final < ga < release < sp.
Other words are compared letter by letter and case matters: capitals come first, so 1.0-M1 < 1.0-alpha1 and 1.0-Beta1 < 1.0-alpha1.
A version with an extra word part is lower than without it (1.0-final < 1.0, even 1.0-sp1 < 1.0); an extra number part makes it higher (1.0 < 1.0.0). The separators do not count: 1.0-1 and 1.0.1 rank the same.
Related: Maven version range checker (same brackets, different rules on betas) and NuGet version range checker. For npm, Cargo, Composer, pip and RubyGems, use the Version Constraint Checker; to sort versions, the Version sorter; for betas, what each package manager installs when a beta is out.
1.+ matches every version whose text starts with "1." and Gradle takes the highest one. It is a text prefix, not a semantic rule: betas and release candidates are included. We ran Gradle with 1.0 and 1.1-rc1 published: 1.+ resolved 1.1-rc1. With 1.0, 1.9, 1.10 and 2.0 published it resolved 1.10, because 10 is higher than 9.
Without a dot, the prefix is just "1", and "10.0" and "11.2" start with "1". With 1.0, 1.5, 10.0 and 11.2 published, 1+ resolved 11.2. Write 1.+ instead. The same trap exists one level down: 1.1+ matches 1.12.0.
No. For an excluded upper bound, Gradle also leaves out every version whose text starts with the bound, so 2.0-rc1 and 2.0-beta1 are skipped. With 1.0, 1.5, 2.0-rc1 and 2.0 published, [1.0,2.0) resolved 1.5. Maven handles the same range differently and would take 2.0-rc1. Betas below the bound still count: [1.0,) resolved 3.1-alpha1.
No, not in a Maven repository. There, only -SNAPSHOT versions have the status "integration"; everything else is a "release". With 1.0, 1.1 and 2.0-rc1 published, latest.release resolved 2.0-rc1. latest.integration also takes -SNAPSHOT versions.
It is the version Gradle asks for, but not a hard limit. If another library in the build needs a higher version, Gradle's conflict resolution takes the higher one. For a hard pin, use strictly, for example implementation("g:a") { version { strictly("1.2.3") } }. [1.2.3] is read as the plain version 1.2.3.
No. Gradle does not know these signs and reads the whole text as a fixed version, so the build looks for a version literally called "^1.0" and fails. Use 1.+ for "any 1.x" or a range: [1.0,2.0) for ">=1.0 <2.0", (1.0,) for ">1.0".
For Go programs: the same rules as a library, github.com/Lawatch/10aday/verrange/gradle (open source, no dependencies, tested against the Gradle 8.14.3 classes and real Gradle builds).
From a terminal, with Go installed: go run github.com/Lawatch/10aday/verrange/cmd/verrange@latest gradle "1.+" 1.0 1.9 2.0 prints yes or no for each version, then the one the tool would pick (command docs).