Of course, if you never upgrade the system, why do you care about the version you install being an LTS, rather than one with the features you want?
In practice, though, people do get upgrade breakage on LTS systems - they take changes that are deemed "bug fixes", and those can break things, since the category "bug fix" is (like all human classifications) fuzzy around the edges, and includes things that break workflows, or that stop the system functioning.
And as soon as you start taking any changes at all (even "bug fixes only"), you get into the mess that people make mistakes; they can classify a "bug fix" as a "feature change" and not fix it, or classify a "feature change" as a "bug fix" and accidentally introduce an unwanted change into the LTS system. They can make mistakes and thus have a "bug fix" not fix the bug it's supposed to fix, or even introduce a regression.
It's not at all clear that a project that hasn't planned very carefully for LTS designs (with a decent test suite, change management processes including things like ECOs for every feature, not just change logs, a process for ensuring that bugs are fixed in all active versions - which probably involves adding more tests - and more) actually can do this well - there's a huge amount of work in doing LTSes properly, and just "slow down the release schedule" isn't nearly enough.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。