When should we upgrade to a new version?

Having an upgrade strategy is important. If you can, always go for small incremental upgrades, but sometimes you have to do larger upgrades.

Large upgrades

Monolithic backend frameworks and databases are some of those systems, where you have to do large upgrades and plan it a long time in advance.

Here's a couple of tips on how to do large upgrades in a huge organisation:

• Enterprise Software Upgrades: Less Pain, More Gain by Christopher Koch (it's pretty old, but still relevant in some circles)

• 17 Essential Steps In The Software Upgrade Process by Meredith Henson

• A Project Manager’s Guide to a Trouble-Free Software Upgrade by Lindsay Sullivan

Small upgrades

When doing small upgrades, it's really important to understand what to update when.

Most, if not all, open-source software follow the Semantic Versioning system, also known as semver. The official website linked previously provides a pretty good description of the system, but I often refer to this write-up by the GitVersion folks when introducing it to new developers.

Once you understand what's updated, it's a lot easier to make strategy.

For instance:

• patches are installed a week after they're out with no extra effort with respect to testing,

• minor updates are installed two weeks after they're out with in a separate environment and tested carefully using automated systems only, and

• major updates are installed a month after they're out in a separate environment and tested carefully using automated and manual systems and with thorough attention to the release notes. Must be reviewed and manually tested (both source code and running in staging) by several lead developers before it can be merged.