Why is LATEST a dependency management anti-pattern?

Question

I was in a code review (for my code) lately, and an architect saw the following in my build.gradle file:

dependencies {
    compile 'org.apache.commons:commons-lang3:3.3.2'
    compile 'org.apache.httpcomponents:httpclient:4.3.2'
    compile 'com.fasterxml.jackson.core:jackson-annotations:2.3.0'

    // The problem:
    compile 'org.ourcompany:widget-client:LATEST'
}

To this he stated: "Using LATEST is a dependency management anti-pattern, don't do this." I was tempted to ask "why?", but I didn't.

I did this because the widget-client JAR version changes multiple times a month, and it became a nightmare trying to remember to update my Gradle build with the latest version number. Worse, I've lost a lot of time debugging and troubleshooting issues arising from us not have the latest widget-client version. So this was my fix.

Before I push back and lobby for us using LATEST, I'd like to be well informed. Perhaps the architect is correct, in which case, I'd like to know why and, more importantly, what the solution is (so I don't have to update my Gradle build twice a week). And if he's not correct, I'd like some reasons as to why.

Another thought I had was that perhaps it would be possible to tag a particular version of widget-client as being, say, STABLE, and then we could just always pull in the latest STABLE version of it, which perhaps is better than LATEST, but perhaps not... That way, at least, we always have a version of the client that is stable and has been deemed to be functional and well tested, which keeps us off the (potentially buggy) bleeding edge, but still gives me a STABLE label so I don't have to keep updating deps to a specific version.

It really all comes down to why LATEST is bad. If its because it keeps you pinned to the bleeding edge (and hence bugs), then I think a STABLE solution is the way to go, but I don't know enough about this stuff to round out a concrete solution. And if LATEST is bad for other reasons, or not bad at all, then I'm not sure what to do either. Thoughts?

Never be afraid to ask "why" in order to learn. – cjstehno Jan 16 '15 at 21:25 — cjstehno, Jan 16 '15 at 21:25

score 6 · Accepted Answer · answered Jan 16 '15 at 18:26

6

This is bad because it makes the build non-reproducible. If you run the same build with the same source a few days later, the result may be different because another version of the dependency is used.

Things get even worse, if this dependency depends on other libraries that may than also change their versions and maybe clash with your libraries.

So in fact, you don't manage dependencies when you use LATEST.

answered Jan 16 '15 at 18:26

Henry

42,982
7
68
84

Thanks @Henry (+1) - so that answers the *why* but doesn't address the solution. Am I really forced to upgrade my version multiple times a week, or is there a middle ground (such as my `STABLE` solution) here? Thanks again! – smeeb Jan 16 '15 at 18:34
The STABLE variant does not really change the fundamental problem. Assume you test your source locally and everything is fine. Then you check it in, the build server compiles it again and the resulting version is broken because the dependency changed in the meantime. The best way is to make version upgrades intentionally after checking the risks and benefits. – Henry Jan 16 '15 at 18:38

Why is LATEST a dependency management anti-pattern?

1 Answers1