Julian Foad wrote on Mon, 25 Jun 2018 11:31 +0100: > Daniel Shahaf wrote: > > Julian Foad wrote on Fri, 22 Jun 2018 14:26 +0100: > >> 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. [...] > > > > That was a very clear explanation, thanks, and it makes sense. I agree > > we should keep 1.9 users' expectations in mind. I am concerned, > > however, that making 1.9 LTS does mean that for the two months after > > 1.13's release, we'd be supporting four release lines simultaneously: > > 1.9, 1.10, 1.12, 1.13. Are we sure that's not more than we can chew? > > I don't see any problem. Firstly, we haven't (yet) promised any overlap > period, although it would be unreasonable not to have any overlap so we > should certainly aim for something like that and maybe state it > explicitly. But in any case we do not promise any minimum amount of > support -- we do not promise to release at least N backports per release > line, or to backport a particular fix to every supported line within N > days --
Suppose a security issue is found that affects "1.9 and all later versions", don't we (implicitly) promise that the fix therefor would be announced for all supported release lines simultaneously? I agree that non-security bugfixes are backported on a "no promises (volunteer-led project)" basis. > so if we are struggling then the support period of one or more > of the older release lines will simply expire before we get around to > it, and that is just "tough luck" or in other words the normal operation > of a volunteer-led project. > > So I am not worried about that. Cheers, Daniel