IIUC your use case this is not the kind of branch that gets merged back, it's more of "another trunk" whose version is largely frozen and that may get backports and fixes.

I've done that. It signalled that the customer had a lack of faith in the stability of our releases.

In our case it was a valid concern (our team had a pretty awful track record).

Apparently you have never sold to a fortune 500? Many require bug fixes only of your app for X years. They don't care about new versions. Nothing about faith but about their priority. Using the latest and greatest is not their priority.

We were selling to Fortune 500s.

The upgrade paranoia only kicked in when they were subjected to broken releases and had to roll back.

The F500 is incredibly varied in their requirements even within the same company. I've seen demand for new features and long term, keep-everything-the-same-as-day-one from the same group for different services / products. Paying more money to keep things from not changing or for not adding features is something unique to enterprise environments though.

Well, sometimes the lack of stability is purposeful - new features are added, old features are deprecated, etc. How do you deal with that?

What languages do not support the equivalent of #ifdef in the C world, such that you can have variations in actionable code without having permanently separated code branches?

OP: this works for Google and Facebook, if you don't use it, you're dumb.

I'd quite like to load the LTS version of GMail and Facebook. I'd also like to have some say in how these apps I use every day work. Unfortunately, I have no say. I'm not even the customer.