Upgrading Dependencies: Make it a Habit
Every team approaches upgrading the dependencies in their apps differently. Most teams don’t have a coherent policy. Generally, that’s not out of laziness. It’s really hard to establish a policy that makes sense. Over the years, I’ve found a policy that makes sense for most of our projects. Here it is: upgrade at a set time in your development cycle, preferably when you will have the maximum amount of testing over that upgrade.
That means if your team releases every month, spend a day when you start working on the next release running upgrades. You’ll catch a lot of issues in your tests, but you’ll also have all of the time during the development of that release to find any remaining issues.
If your team releases continuously to production, then you’re already relying on your automated test suite to catch any issues. Dependency changes shouldn’t be treated any differently.
Yes, I can hear your groans. Doesn’t this approach mean you’ll be spending some amount of time ever so often working through breaking changes, bugs, etc. Yes, but here’s the truth. Frequent, incremental library upgrades are way easier to handle than the alternative. Facebook operates this way. They intentionally point everything to the latest version in development so that they discover incompatibilities as soon as possible. Furthermore, it’s highly likely that many of those updates include security updates. You wouldn’t intentionally leave your network infrastructure or OS un-patched. Why do the same with your application?
Here’s some questions I always get:
Should you treat the programming language any differently? No, unless there is a major syntactic change. Even in those cases, most languages will deprecate old syntax with a warning. If you’ve done the upgrade at the start of a release cycle, you’ve now got time to change the deprecated syntax.
Do you have to always update everything to the latest version if there is a complex breaking change or you want to wait for it to be more mature? No, you can absolutely set policies on this. For example, you might decide to only upgrade your language version on a major version bump after 3 months of release. That’s a perfectly rational decision, but stick to it.
How does semantic versioning impact this? I’d say it’s the same approach as above. If you know the library author is following a versioning pattern and/or publishes a CHANGELOG of some sort, read it.
What if I don’t have a good test suite to catch issues? The right answer is to improve your test suite. Even if you just change code, you’re already running a risk you’ll break something.
Ultimately, dependency updates are a part of the development process. Many people see it as a nuisance or something to take on only when an old version is about to lose support. Have an approach to it, experiment with it, and find an approach that works for your team. The only wrong decision is to ignore it.
