# Dependency Upgrades Are Reliability Work

> The least popular reliability work. Skipping it costs more than linearly.

Source: https://christwentyfour.com/blog/dependency-upgrades-are-reliability-work

Upgrading dependencies is the least popular reliability work. It ships no feature, sometimes breaks something, and its payoff is an incident that never happens. The cost of skipping it is not linear.

## Debt compounds

One minor version behind is a fifteen-minute upgrade. Two years behind is a project. The API changed. The config changed. The migration guide assumes you did the steps in between. The cost climbs every week while urgency stays at zero, so deferring always looks reasonable. The result is a system nobody can safely change.

The painful case: a critical vulnerability in something eight major versions behind, where the patch only exists on a line you cannot reach in an afternoon. Now an urgent fix is a three-week migration, done under pressure.

## Small and frequent wins

Automated update pull requests run the full test suite and get reviewed like any change. That works only if the tests are trusted and the pipeline is fast. Otherwise the updates pile up unmerged, which is the same debt in another queue.

## Treat patches and majors differently

Batch patches and merge them when green. Give majors a ticket, a changelog read, and a deliberate timing decision.

## Track the oldest dependency

Track how far behind the oldest one is, not how many are outdated. One four years stale is a bigger risk than forty that are one release behind.

The honest argument is optionality. A current system can take a security patch in an afternoon. A system two years behind needs weeks.