Updating dependencies in Android project – my approach

Lately, in my current project, we had a discussion about the approach to update dependencies. New versions are released – some bugs are fixed, some newly created, sometimes we have breaking changes, sometimes it doesn’t’ change nothing. What, when and how to update? In the ideal world, everything would be automated, but does everything should be updated periodically? Do we want to update also major or only minor version? Maybe just patches?

TL;DR Real automation failed, but I use tools to have a semi-automated process that I go thought periodically. If you don’t want to read about the tools go to the last section.

How to automate updates?

First of all, I tried to research possibilities to have a fully automated process. Maybe there are some tools that solve our problems. Also around these tools, we could find a community that has answers to our questions. There are two very interesting tools:

1. Repository Gardener

The repository gardener maintains code samples by running some automatable tasks. For example, it can automatically update dependencies and then after running tests to ensure they still work, send a Pull Request for the update.

Looks like a great thing that can check for new versions and create Pull Request for you. Unfortunately, it works only when you have dependency versions in the main Gradle file and when you use Groove. In all of my large projects, I try to extract dependencies and other configurations to separate files to have it more maintainable. Also, I am a fanboy of Kotlin, in the script version either. When you check how it works you can see that there is quite a simple Python script that works on raw file content and parse Strings. This is a risky approach and definitely not a flexible one.

This is the best that I found for automation of the updates but this is far from perfect.
I decided to drop usage of this library that doesn’t fit my projects and it would need a lot of time to adjust.

2. Gradle Versions Plugin

In the spirit of the Maven Versions Plugin, this plugin provides a task to determine which dependencies have updates. Additionally, the plugin checks for updates to Gradle itself.

Usage: ./gradlew dependencyUpdates
This plugin is super simple and allows you to define which libraries you want to update and which versions do you accept. You can have simple text output as below or JSON. You can also define your own format.

You have to remember to define what you consider as an acceptable version.
According to documentation:
“To further define which version to accept, you need to define what means an unstable version. Sadly, there are no agreed standard on this, but this is a good starting point”

def isNonStable = { String version ->
    def stableKeyword = ['RELEASE', 'FINAL', 'GA'].any { it ->
        version.toUpperCase().contains(it)
    }
    def regex = /^[0-9,.v-]+(-r)?$/
    return !stableKeyword && !(version ==~ regex)
}

dependencyUpdates {
    rejectVersionIf {
        isNonStable(it.candidate.version)
    }
}

This is not an auto-update tool but it helps a lot. You don’t have to check every dependency on your own. Repository Gardeners also use this tool to determine which dependencies need to be updated.

How to update without automaton?

After the above research, I dropped the whole idea of auto-update dependencies. Maybe it’s even better because auto-updated could be risky and could create a lot of unplanned work. Manually update will be more conscious and also will allow you to lean over the changelog of the libraries. You can find sometimes interesting things there!
So how I would do that?

  1. After releasing a new version
  2. Run dependencyUpdates task and generate a report about stable updates
  3. Create a task to updated dependencies with attached report
  4. Give this task a high priority and take it to the next sprint
  5. Next release version will have new dependencies

Why I check for a new version after release? That will give me more time to test these dependency updates and I can do it more conscious without having a releasing process in the back of my head. In the perfect world, you should have the above process in your CI/CD tool (first 3 points).

There are still questions about what you should update, which versions – major, minor, etc. Well, I don’t have an answer to that. It depends. But thanks to the above process you can be more aware of the possibilities. You have to decide on your own and take responsibility for compromises. Ignorance isn’t bliss.

What is your approach to update dependencies? Do you update them periodically? Do you have some tools for that?

Have a great day!
See you on The Code Side
Artur Latoszewski

Add a Comment

Your email address will not be published.