Ruby always gets a new major release on Christmas Day, this year it’s going to be 3.4. Since July this year the release team have said they’ll do point releases every two months, faster if they need to fix a regression. Rust has a six week release cycle for the stable branch. Node does major version releases every six months, even numbered versions in April, odd numbered versions in October. Even numbered Node versions are Long Term Support versions that are actively maintained for a year and supported for a further year and a half after that.

These are all different schedules but they are regular. This means you can plan your own maintenance work around them. Unless your organisation is large enough to have a dedicated team you likely don’t want to be on the latest major version as soon as it’s out. So if there’s no compelling reason then running one major / LTS version behind is usually a good strategy to avoid library or dependency issues and still get security and bug fix updates.

Running the next version in your CI once a day, or once a week, will pick up any potential issues. With regularly scheduled canary builds based around the release schedules of the tools you use you know what you need to fix to update your code. Schedule it in as regular work so you don’t have to do a burst of update work when you want to change versions. If you make the codebase work on your current versions plus the next version you’re upgrading too it means no drama when you do update.

How out of date is your current tooling? Are you doing canary builds with later versions of the tooling you rely on?