How to update Gradle dependencies to their latest version

Question

Is there an easy way to get gradle to update dependencies to their latest available version?

For build reproducibility all my dependencies are defined with a version number like this in my build.gradle file:

dependencies {
    compile 'namespace:package1:version'
    compile 'namespace:package2:version'
    compile 'namespace:package3:version'
}

Periodically I want to update every package to their latest version. Typically this is the first thing I do for a new sprint after making a release.

It's a real pain doing this manually for each package. Ideally I would like a command to update the build.gradle file for me but at the very least a command that prints out which package needs an update and what the latest version number is.

In ruby land I would run bundler update.

Solution 1

This is all I've been able to come up with. I will happily accept another answer if there is a less manual method of doing this.

1. In Android studio I replace every dependency version with a plus example: compile 'namespace:package1:+'

2. Sync or build the project which will cause all the dependencies to be resolved to their latest version.

3. In Android Studio place the cursor on each dependency line in build.gradle and press alt+enter a menu pops up and you can select Replace with specific version

Solution 2

Add to build.gradle:

plugins {
  id 'com.github.ben-manes.versions' version '0.17.0'
}

Then you can do gradle dependencyUpdates to get a report of new versions. Unlike the eponymous Maven plugin, there doesn't seem to be a way of automatically updating the build.gradle yet.

More documentation: https://github.com/ben-manes/gradle-versions-plugin

Solution 3

It is not a really good practice as libraries can include changes that may break your code.

A common "tolerated" syntax for

compile 'namespace:package:major_version.minor_version.revision'

would be like

compile 'namespace:package:1.0.+'

considering revision is used by the library authors as bug fixes and improvements updates

Note: I just did that and you could do

compile 'namespace:package:+'

---

Edit:
A Proof Of Concept of my latest comment you may want to test.
This was made in 5 minutes, so don't expect it to be perfect nor flexible.

Solution 4

I suffer from it, too. And the best way to check dependencies, even manually, is to go through Project Structure and search for the dependency name and see if there is a newer version.

The problem that this query only checks for the dependencies present in the Maven repository. At least it already goes for Google's.

Note: If you choose to add the dependency with the new version, this will add a duplicity in the your App Gradle, so be sure to delete the old dependency row.

###################

Another possible quick fix is through the command line:

./gradlew app:dependencies

This will generate an output like the one below. Note that the asterisk points to a possible new existing version.

View more solutions

Comments

[Jintin]

I've wrote an python tool to update the version of dependency, you can give it a try. github.com/Jintin/andle

[Suhaib]

Possible duplicate of How to check if gradle dependency has new version

[patrickfdsouza]

@Suhaib is right, stackoverflow.com/a/28683488/2763883

[Jay Patel]

You can use this site and search any dependency's latest version: gradleplease.appspot.com

[Jared Kells]

Yeah I understand you can replace part of the version with a + to resolve the latest version at build time but that breaks build reproducibility. I want to depend on a specific version as is best practice and occasionally update every package.

[Gorcyn]

An update to a specific version ? Major, minor or revision ? compile 'namespace:package:1.0.+' would update to latest revision as compile 'namespace:package:1.+' would update to latest minor version and compile 'namespace:package:+' to latest major one.

[Jared Kells]

I don't want to put a plus because that means every time I run the build I could get a different version of the library. During most of the development process the version must stay the same so it can be thoroughly tested.

[Jared Kells]

Typically after a release I want to update every library to their latest version. This will be done every few months. The dependency tools I use in other languages support this. NuGet and bundler are examples.

[Gorcyn]

Ok I get it, you don't want latest versions at compilation time but at some point when launching a tool then a dependency to compile 'namespace:package:1.0.0' would get updated to compile 'namespace:package:1.0.1' automatically. You should update your question to make that clearer :)

[Gorcyn]

A script that would modify to namespace:package:+, then gradlew --refresh-dependencies then namespace:package:x.y.z where x, y and z would be read from .idea/libraries/*.xml. Quite an interesting feature.

[Ben Manes]

See the gradle-versions-plugin.

[Lukas Novak]

@Ben Manes: This should be accepted answer. Great plugin, good job!

[Ray Li]

This answer is the best way to check for updates! Remember to build the project in step #2 or else it will not work.

[Marian Klühspies]

In my case, sync does not neccessarily download the latest version. It seems there is some timeout set to the cache until it re-checks the server version

[starkej2]

I don't think an asterisk means there's a possible new version. It says this at the bottom of the dependency tree: (*) - dependencies omitted (listed previously)

[mernst]

There is now a way to automatically update dependencies: github.com/patrikerdes/gradle-use-latest-versions-plugin

[n13]

Thanks - there's now a "suggestions" tab all the way down in project structure where it suggests all updates. Much better than taking random stabs at versions in the xml files.

[Filip Kubala]

I'd say this is a pretty risky method. You stop controlling what version you have installed locally, what your teammates are using, and what will e.g. be on the server because some library update will come, right before the release. I know this is a similar solution to ^ in JavaScript frameworks, but there we have a package lock file, which is controlling what version exactly is used across the whole team / environments etc.

[Marco Lackovic]

@mernst your solution is the best, it should be a separate answer to have the visibility it deserves