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 -- 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. > I also wonder what happens if we find that our releases are spaced > further than six months apart from each other. I suppose that if our > releases turn out to be, for the sake of example, 12 months apart, we > could consider making 1.12 an LTS release and EOL'ing 1.9 at that time, > rather than upon 1.14's release. Time enough to worry about this situation > if and when it happens, I suppose. Yes, if and when it happens. - Julian
