The difference is in the amount of validation needed with a "proper" LTS process.
If I have good ECOs for every change in the update, telling me precisely what changed and why, I can limit my testing to system interactions plus anything affected by the things changed in the ECO.
In contrast, if all I have is a standard changelog (like the Linux kernel provides), I have to retest everything, because I can't be sure that a change described as "fix r8152 hang during runtime PM" only touches the r8152 driver - it could (and probably does) touch USB core stuff as well.
My personal bias is therefore to say that frequent small releases, and no big releases, are the right thing for most projects; if you're not putting in the effort to put out a decent ECO for every change in your LTS branch that allows people to omit chunks of validation as "not necessary", then you're not saving those of your customers who care about reliability any effort, and you are adding work for yourself deciding which changes need backporting, which ones need splitting (so that the bug fix can be backported without the attached feature work) and which ones need rewriting for the LTS (to get a bug fix that doesn't depend on work that isn't going to be backported).
It's worth noting, too, that the longer the LTS lasts, the more changes that will need rewriting for the LTS, and thus the more work you're signing up for; and for this work to avoid a need for full downstream revalidation, you're going to have to produce decent explanations of what's changed so that downstream can just revalidate system interactions, not everything.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。