Reasons to keep codebase dependencies up to date

Major and minor versions

I often use terms “major version” and “minor version” in this blog post. It's important to understand the difference between them, so before proceeding further lets clarify it:

• Major version — a completely new version of a software tool. Keeps most of the features of the previous version. But introduces new features and breaking changes. E.g. 2.0.0 vs 1.0.0 (I use semver approach in examples here and below).
• Minor version — a version of a software with minor modifications or updates. Usually keeps exactly the same features as the previous version, and doesn't introduce breaking changes (at least tries not to introduce them). E.g. 2.0.0 vs 2.0.1 or 2.1.0 or 2.1.1.

Now as the major terms are explained, let's get to a few reasons why keeping software project dependencies up to date is important.

Reason #1 — Bugs and security fixes

This is the most often reason behind a new version release (usually minor). Very unlikely that your project will hit a bug of a popular software lib in a major flow. Thus in general it's ok to be not so paranoid about upgrading on every single minor version release. However I would recommend strictly following security patches and updates, for obvious reason.

Even though a bug or security update is intended to only fix an issue or security flaw it's not rare for it to introduce breaking changes. That's why it is important to test software product before releasing it into production, even with minor dependency update.

Reason #2 — Performance improvements

Performance updates happen less often than bug and security fixes as they require more efforts from developers. That's why changes that significantly improve performance are usually introduced in major version releases. Though fixes of the bugs that cause performance issues in some cases are not rare in minor builds.

Reason #3 — New features

This is the most obvious reason why one would want a new version of a software tool. New shiny API in many ways may be an opportunity to build new features on top of it, and thus improve the product. But there is a caveat.

Unfortunately switching to a major version usually requires changes to the codebase. This is because API may significantly change, or some other dependencies rely on the updated package and require modifications as well. So, switching to a new major version may become a long and sometimes painful journey.

You decide when to update

The decision of how often to update is always up to you. Almost always skipping an update will not critically hurt a project. And of course there may be other things with higher priorities to do, which is normal. So, it really depends on how far would you want to go in keeping your codebase fresh, bug free and performant.

From our experience updating dependencies once per month is enough for almost any project. Book a few hours of a project developer in the beginning of each month, as the end of a month is often a release time for packages vendors. Run through all minor updates, and plan heavy updates for later stages if it's not the right time for them. And you are good! Just make a rule to do it on a regular basis.