The Dependency Update Lottery

There is a special kind of optimism that comes with running a dependency update.

You look at the list and there are 47 packages that are out of date.

You think: “That’s fine. I’ll just update them.”

This is where the lottery begins, because there are two possible outcomes.

1 - Nothing happens

• You run the update.
• It downloads a load of things.
• A few version numbers change.
• You run the tests.
• Everything passes.
• You open the application.
• Everything still works.

You sit back and think: “That was easy.”

You might even update a few more, which is dangerous, because now you have confidence.

2 - Everything happens

The other possibility is that you update one completely innocent-looking package and suddenly the entire application falls apart.

Something has changed. (You don’t know what.) The error message doesn’t appear to be related to the package you updated.

Something that worked perfectly five minutes ago is now throwing an error about something completely different.

You start investigating and an hour later you’re reading a GitHub issue from 2021 written by someone called darkwizard87 who apparently solved the exact problem by changing one line in a configuration file that you didn’t know existed.

Panic

• You try it.
• It works.
• You have no idea why.
• You don’t care.
• You commit it.

The real lottery

The problem isn’t usually updating a dependency, it’s the dependencies behind the dependency.

You aren’t updating one package. You’re updating a small ecosystem of packages, each of which depends on something else, which depends on something else, which depends on something else.

You ask for: “Update Package A.”

Package A says: “Sure. I’ll also update B.”

B says: “Fine. But I’ll need the newer version of C.”

C says: “No problem. But that version of D is now deprecated.”

D says: “LOL.”

And suddenly your perfectly stable application from Tuesday is running on completely different versions of half the internet.

And then there are the major versions

Minor version? Probably fine.

Patch version? Probably fine.

Major version? Stop.

1. Put the coffee down.
2. Read the documentation.
3. Check the migration guide.
4. Check the GitHub issues.
5. Search Google.
6. Search Reddit.
7. Check whether anyone else has tried it.
8. Then make a backup.
9. Then make another backup.
10. Then perhaps consider whether you actually need to update it.

Because “breaking changes” is generally developer language for: “We changed something that you absolutely relied upon without realising you relied upon it.”

The particularly annoying ones

Some updates are even more fun because nothing breaks immediately.

• The application starts.
• The tests pass.
• Everything looks fine.

Three days later, something completely unrelated stops working and you eventually discover that the dependency update changed something buried six layers down in the dependency tree.

You then spend an afternoon trying to reproduce a problem that only happens on one particular server running one particular version of PHP with one particular combination of extensions.

At this point, you start considering a career in gardening.

So I have a system

My system is fairly sophisticated.

• I update 1 thing.
• Then I press F5.
• If it still works, I update something else.
• Then I press F5 again.
• If it doesn’t work, I stare at the screen for a while.
• Then I press Ctrl+F5.
• Because obviously that will help.
• It probably won’t, but developers have traditions.

The temptation to leave everything alone

There is also a perfectly reasonable argument for not updating anything.

If the application works, don’t touch it?

This is particularly attractive when you discover that the current version of something is several years old and has been quietly doing its job without complaint. Unfortunately, dependencies don’t always respect this philosophy.

Eventually you get the warning. Then another warning. Then a security advisory. Then another package announces that it no longer supports your version.

Eventually you’re no longer maintaining an application, you’re maintaining an archaeological site.

Dependency management is basically choosing when you want to experience the pain.

You can update little and often and deal with small changes regularly. Or you can leave everything for two years and eventually spend three days discovering that seventeen major versions have passed and absolutely nothing is compatible with anything anymore.

Neither approach is particularly exciting, but at least with regular updates, when something breaks, you generally know what broke it. And that might be the most important part. Because the moment you update 38 dependencies in one go, you’ve stopped doing software maintenance.

You’ve bought a lottery ticket.

And you’re just waiting to see whether you won.