<div dir="ltr"><div dir="ltr">I suggest everyone takes a read through 

<a href="https://en.wikipedia.org/wiki/Long-term_support">https://en.wikipedia.org/wiki/Long-term_support</a> as to what LTS is actually meant to be focused on.<div><br></div><div>What you (Ben and Matt) are both describing is not LTS but STS ... these are different concepts.</div><div><br></div><div>For LTS the focus is <b>stability </b>and <b>reduced risk of disruption </b>which alters the judgement on what is appropriate to put into a release.</div><div>It then becomes a test of "is this bug fix worth the risk" with the general focus on lowest possible risk which stops this sort of thing happening unless a critical feature is broken.</div><div><br></div><div>All of the "edge case" examples presented all involve substantial changes to implementations and carry an inherent risk of breaking something else - and that is the issue.</div><div>It would be different if we had a full regression test suite across all the platforms and variations on platforms that our users are operating on - but we don't.</div><div><br></div><div>We don't compare performance between releases or for any updates in our test suite so it isn't part of our scope for release readiness - if this is such a critical thing that must be fixed then it is something that we should be measuring and checking as a release condition - but we don't - because it actually isn't that critical. <br><div><br></div><div>Tim.</div></div><div><br></div></div></div>