I’m still not sure I’m understanding this correctly. I’ve never used Node.js, so I don’t know what that term means in that context. My only substantial relevant Linux experience comes from CentOS, where, as I understand it, each major release (“CentOS 6”, “CentOS 7”, etc) would get security fixes and some/all* bug fixes back-ported to whatever version of all the tools and libraries that release originally shipped with, but otherwise nothing that might change the behavior of the system would get updated. As I understand it, this is done to give developers and sys admins a “stable” target. It’s telling them (more or less) “oh, yes, you can just install all the updates without worrying that Python 2, which this release originally shipped with, will get updated to Python 3 and break half your stuff”. It’s about prioritizing compatibility & reliability over “latest & greatest”, which makes a ton of sense for a lot of use cases. When I hear “LTS”, that’s what I think of. Am I understanding the term correctly?
If so, I’m not sure how it helps. The idea is “prioritizing compatibility & reliability”… WRT the “compatibility” part, we already have source and binary compatibility requirements. WRT the “reliability” part, I’m sure the Swift team is trying to fix this bug now that they’re aware of it.
Given that bugs happen, it seems to me that the core of the issue is that testing didn’t reveal the problem ahead of time. So wouldn’t the solution going forward be to improve the testing methodologies? If so, why wouldn’t the same improved testing get applied to non-LTS releases? I don’t think you’re suggesting that regular, non-LTS releases should ship with major bugs, but I’m not sure how that kind of situation isn’t an inescapable consequence of having LTS releases with more stringent testing than the regular releases.
* Probably Off-topic
It wasn’t ever clear to me if “load-bearing” bugs that didn’t have security implications would get fixed, but that’s probably not an issue here.