Daniel Shahaf wrote: > Julian Foad wrote on Fri, Jun 22, 2018 at 12:27:21 +0100: > > Done in http://svn.apache.org/r1834111, > > "Publish our new 6-month standard and 2-year LTS release schedule." > > In practical terms, we have now promised to release 1.11.0 around October, so > we should start thinking of cutting a 1.11.x stabilization branch around late > August / early September.
Yup. > The new documentation states that 1.9 would be an LTS release, to be supported > until 1.14; I had assumed 1.10 would be an LTS release (supported until 1.14 > is > released + overlap period) (and then supported with security/corruption fixes until 1.18 is released) > but 1.9 would be a "normal" release, to be supported > until 1.11 is released. That would be consistent both with the guarantees > made > when 1.9 was released and with the new "1.x is LTS if (x%4 == 2)" practice. Previously we did not lead users to think that some releases were going to be supported much longer than others so it was reasonable for any user to choose 1.9 as the release they plan to use for a longish period (say 4 years) and expect it will be supported (with security/corruption fixes) for about that time. That is why I think we should keep the support period for 1.9 as one release (until 1.10) for general fixes plus 2 years (being roughly the same as one old release cycle period that would have been expected) for security/corruption fixes. Another angle on this: I interpret what we are doing as inserting extra mini-feature-releases into the existing cycle, rather than compressing the existing cycle to happen four times faster. So telling a user that "the next release" they were expecting is suddenly going to be a quick mini-release would be an unwelcome surprise in terms of support stability. (Hopefully at the same time a welcome surprise in other ways.) What do you think? - Julian
