Upgrade Your Dependencies Before You Have To

An up-to-date application is easier to secure, faster, and cheaper to maintain than one that’s fallen behind. Most teams still treat upgrades as a project. It gets scheduled once the framework drops out of support, takes a quarter, and ends with everyone vowing never to fall that far behind again. Then they fall behind again. Upgrading should be a habit instead: small, frequent, mostly automated, and backed by a test suite you trust.

What staying current buys you

Security comes first. Vulnerability fixes land in current releases. Every framework has a support window, and once your version drops out of it, the next CVE gets patched for everyone except you. Your options at that point are a rushed multi-version upgrade under incident pressure, or a hand-rolled backport that you now maintain forever.

The rest of the benefits are quieter. New versions bring performance work you get without writing any code; Ruby 3.2 declared YJIT production-ready, which put a faster JIT one flag away for any app that upgraded. They bring bug fixes for problems you may have been working around for months. They keep you compatible with everything else that’s moving: a new OS image, a newer database, a cloud provider retiring an old runtime. An outdated library pins you to old versions of everything around it.

And libraries die. An abandoned gem with no maintainer is technical debt that grows every month you keep depending on it.

Big-bang upgrades are where the cost hides

Picture an app three major Rails versions behind. The upgrade is every deprecation from three release cycles landing at once. Gems that stopped supporting your version years ago need upgrading too, some of those have breaking changes of their own, and one turns out to be abandoned and needs replacing. The upgrade branch lives for weeks and drifts from main, and every merge back is another round of conflicts. When forty tests fail, nobody can say which change broke which test.

Now picture doing it one step at a time. The Rails upgrade guide recommends moving one minor version at a time so you can make good use of the deprecation warnings, and that advice applies well beyond Rails. A deprecation warning is cheap to fix while there are three of them. Each bump is a PR small enough to review. When something breaks, the diff that broke it is a few lines of lockfile.

Make deprecations loud so they get fixed as they arrive:

ruby # config/environments/test.rb config.active_support.deprecation = :raise

For the jumps that are still big, dual-boot. Keep a second lockfile pinned to the next version and run CI against both, so the upgrade happens on main in small commits. Shopify’s bootboot gem is one way to set that up.

Automate the boring part

Nobody should have to remember to check for new versions. Dependabot and Renovate both open pull requests on a schedule, and grouping the small bumps keeps the noise down:

yaml # .github/dependabot.yml version: 2 updates: - package-ecosystem: "bundler" directory: "/" schedule: interval: "weekly" groups: minor-and-patch: update-types: - "minor" - "patch"

That’s one PR a week for the routine updates. Major versions still come through on their own, because they deserve a person reading the changelog. At the other end, patch bumps to development dependencies that go green are good candidates for merging with no human in the loop.

Every dependency is an upgrade you’ve signed up to repeat for as long as the app lives. That’s one more argument for not installing the trivial ones in the first place.

The test suite makes it safe

Automation only opens the PR. Deciding whether to merge it comes down to your tests. With a suite you trust, a green Dependabot PR is a two-minute decision. Without one, every upgrade is a bet. People stop taking bets, the PRs pile up, and eventually someone closes all of them and the team is back to big-bang upgrades.

Trust matters more than coverage numbers here. A suite with tests that make network requests goes red for reasons that have nothing to do with the upgrade, and after a few of those, nobody believes red. Upgrades break things at the seams: serialization, authentication, the places your code hands off to the framework. Those seams are where tests earn their keep.

Make it routine

Applications change constantly, and so do the libraries underneath them. Regular upgrades are how you keep up with both, and they’re cheapest when they’re small.

Merge this week’s upgrade while it’s a few lines of lockfile.