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
Received on 2018-06-25 12:54:25 CEST