"We'll just stay on LTS" stopped being a strategy when LTS became two years

Linux kernel LTS branches used to carry six years of support. That got cut to two for newer branches, and the stated reason was blunt: the extra four years were mostly theatre. Very few people were actually running or testing those old branches, patches were being backported into code nobody exercised, and maintainer time was going into a promise that wasn’t being consumed.

Predictably, the loudest objections came from vendors whose product plans assumed the six years. Also predictably, most of those vendors were not the ones testing the branches.

What “stable” was actually buying you

The whole appeal of a long LTS is that you pick a version, freeze it, and inherit security fixes without behaviour changes for years. Certify once, ship for half a decade, don’t think about it.

That model has a hidden dependency, and it’s not the maintainer’s willingness to keep the branch open. It’s that backporting a fix into a five-year-old tree gets harder every year the tree ages.

The code around the fix diverges. The subsystem gets restructured upstream. A clean cherry-pick becomes a manual reimplementation of the same idea against different internals, done by someone reasoning about a codebase that no longer exists upstream, with a test suite that’s five years old and a user base too small to catch a regression quickly.

At some point the backport becomes riskier than the upgrade. That point arrives well before the EOL date on the calendar, and nothing announces it.

So the six-year promise was decaying in quality across its own lifetime, and the number on the support page didn’t reflect that. Cutting it to two is more honest about what was actually being delivered. Uncomfortable, but honest.

The position I’ve had to give up

I’ve been a stability partisan for thirty years. Run the old thing. Let other people find the bugs. The newest version’s only proven property is that fewer people have run it.

I still think that’s right tactically — I’m not upgrading production the week a release lands, and neither should you. But I’ve had to concede the strategic version, and the argument that got me was about where the risk accumulates.

Staying on an old branch doesn’t avoid change. It defers it, and deferred change compounds. The team that upgrades every six months does a small, well-understood upgrade with a rollback path, twelve times. The team that freezes for six years does one enormous upgrade, under pressure, when the EOL date finally forces it — across six years of accumulated API changes, config format changes, and behaviour differences, with nobody left who remembers why the original config was written that way.

The frequent upgrader has done the work in small pieces and built the muscle. The freezer has one giant migration ahead of them and no practice. That second position feels safer right up until the moment it becomes the entire quarter’s roadmap.

I was optimising for the risk of any individual change and ignoring the risk of the accumulated delta. That’s a real error and I made it for years.

The vendor problem is genuine

None of which helps if you sell hardware with a ten-year support contract, or run something with a certification regime measured in years, or ship into an environment where every kernel change triggers a requalification that costs six figures.

Those constraints are real and they don’t dissolve because the upstream schedule changed. The answer for that world has always been the same and it isn’t upstream LTS: it’s a distribution vendor who employs kernel engineers to maintain a branch commercially, or it’s your own team doing the same work. Somebody pays for those years either way. The change just made it explicit that the person paying wasn’t going to be a volunteer maintainer.

That’s the part worth sitting with. “Long-term support” from a volunteer project was always a gift, extended on the assumption it was useful to the people receiving it. When it turned out the recipients weren’t testing it, the gift got smaller. That’s not a betrayal. That’s what happens when the feedback loop is empty.

What to actually do

Know your real EOL dates. Not the ones you assumed when the platform was chosen. Check them, this month, for the kernel, the distro, the language runtime, and the database. At least one will be closer than you think.

Upgrade on a cadence, not on an expiry. A scheduled upgrade every six months, in a normal sprint, with a rollback path — a ZFS boot environment makes that a reboot rather than an evening. The point is that the process is boring because it’s routine.

Pay somebody, or do it yourself. If you genuinely need seven years on one branch, that’s a commercial distribution or a headcount. Assuming it will be maintained for free by people who can see nobody is testing it was never a plan.

Stop treating a version freeze as a risk control. It’s a risk transfer — to the future, at interest. The bill arrives at EOL, usually in the same quarter as something else important.