This is an entirely different problem - your customer doesn’t install releases, but they do install fixes? What is the reason for that?

Risk mitigation and investment; my employer's software does critical mobile network infrastructure, if they have an outage it affects millions of people. So, if our customers upgrade the software, they want to do their due diligence in their particular use case (it's a flexible system).

That said though, software should be built to allow for fast and painless upgrades. Backwards compatibility and many use cases should be tested automatically and constantly. But, it's a big investment to have software like that, and you need to resist a lot of younger, eager developers that want to e.g. introduce a new language or make sweeping changes.

Our customers don't want to spend vast amounts of time qualifying an entire new release when they can accept an isolated fix instead and do more focused testing. They might need the fix for some critical part of their product. If I was them I'd do the same - if the rest ain't broke, why risk fixing it?

If the qualifying process is long and expensive, doing a one-off fix does seem more logical. This is assuming you can be sure the fix really is isolated. I do feel like a lot of companies over-exaggerate the need for multiple supported releases.

We have a complex product with many aspects that our customers use, and almost all with some customized integrations.

A bugfix to the integration is typically low risk and high impact, and so the client will want to install that ASAP. For example it could be they suddenly changed the values in a single field in an XML file we read, due to upgrades elsewhere in the organization yay, halting the integration.

So we push a fix where we handle the new values, and they want that installed ASAP.

What they do not want pushed out into prod without lots of testing is all the new things we've added elsewhere in our product, or larger changes to existing features.

The Linux kernel manages to do it with versions many years behind.

No. The Linux Kernel uses release branches. This thread is specifically about rejecting the use of release branches.

Releases are created off the master. Only if something is supported for long a branch is created where only fixes are backported, no development happens there.

What the GP suggested I assume is one master-like branch for every deployed version. Otherwise it makes no sense.

The point remains. The Linux branching workflow is vastly more complicated than what GP advocates.