On Fri, May 1, 2020 at 4:20 PM Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Mark Phippard wrote on Fri, 01 May 2020 18:26 +00:00:
>
> > Since we reached the 6 month mark for 1.13 yesterday, that means its
> > support will continue until 1.14 is released at which point it is EOL.
>
> Can we dig down on this point a bit?
>
> On a macro scale, switching from "we support 1.9, 1.10, 1.13" to "we
> support 1.10, 1.14" is fine. No argument about that.
>
> However, once you dig down into the details, how are administrators of
> 1.13.x installations expected to upgrade to 1.14.x without running an
> unsupported version at any point?
>
> Presumably we don't expect 1.13.x users to run 1.14.0-rc2 in
> production — our RC announcement templates are quite clear about that —
> so I infer that we expect 1.13.x users to upgrade to 1.14.0 soon after
> its release.
>
> All I'm asking is that we quantify "soon".
>
> For example, if we say users of 1.13.x are expected to upgrade to 1.14.0
> within N days of the latter's release, that would mean that we promise not
> to do a 1.14.1 security release within those N days *unless* it's
> accompanied by a 1.13.1 release with a backport of the same fix.
>
> I'm not asking to set N to a large value. I'm just proposing that we
> document _some_ value, even if it's a small one, so users would know
> when to upgrade by.
>
I assume users upgrade when they have a reason to. Once 1.14 is released
our "policy" is that there will not be any additional 1.13 releases. Our
community always has the option of still creating a release if we feel it
is warranted and there is enough support for backporting/signing/RM the
release but we were clear what users should expect. There are already
several fixes in 1.14. If those are important to someone then they will
need to upgrade. If not, they can do it when they choose.
If users were concerned about our support then they could have stayed on
1.10 which still has 2 more years of support.
Mark
Received on 2020-05-01 23:20:32 CEST