Never update anything

I'm not saying RDS couldn't be better, but I wouldn't expect them to maintain unsupported versions of 3rd party software.

We did our upgrades few months back (9.6 -> 13) and luckily in our case it wasn't big of a hassle. Just finding out correct upgrade path with Postgis took some investigation, but overall the upgrade documentation was good.

There are many other examples of this. Breaking compatibility by fixing bugs people rely on for instance.

Any change can break something for a user downstream. It's a very subjective evaluation for the producer to imagine potential impact to their consumers. It's easier if the relationship is rich and exclusive. In open-source where people do it on their free time and have thousands of consumers with widely different interests, it's pretty much impossible to label the release in a way that's conveying the right message to every user.

Semver, the way i see it, is just a way for the producer to subjectively label the amplitude of changes. The consumer should then ideally be familiar with the producer and get a sense of how they work and what they perceive as big. Still at the end of the day it's a very subjective judgment call system that doesn't offer real guarantees to consumers. If your software needs to be stable, don't upgrade, or spend time to review the changes in the dependencies. The version numbers are no guaranty.

I worked in such a project who never upgraded once. And then Specter/Meltdown hit, and we had the mandate to patch all our systems (and the threat was very real). Welcome to a hellish mess of outdated deps that took weeks to sort out.

But is not only me. I watched a talk from a Principal Engineer from Amazon builder tools, and one of their biggest mistakes was not to upgrade often enough, which made each upgrade more painful.

So what do we do now working in multiple, large, multi-year projects?

First, we set tools that tell us when deps are outdated, and alarm when vulnerabilities are found.

Second, upgrading deps is part of the regular dev process. When you make a change, take the chance to upgrade the deps. Vulnerabilities are addressed proactively. The vast majority of times upgrades require no code changes.

Third, we regularly upgrade deps of inactive packages.

Lastly, if a dependency upgrade requires significant work, we create a ticket for it and address it as a new feature. In practice this happens very rarely, so it doesn't disrupt the development process much.

As other's said, the key is to upgrade often, and then it wont be as painful.

Of course those folks don't have these luxuries. npm upgrades without testing, dependency tracking in XML, closed source deps, no symbol versioning, loose dll hell.

But even with simple glibc binaries I have to maintain up-to-date and lts (ie outdated) versions for the recent fstat and time64_t changes. Then you start appreciating go. And podman.