[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Grace period for 1.13 users to upgrade to 1.14? (was: svn commit: r1877222 - /subversion/site/publish/docs/release-notes/1.14.html)

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Fri, 01 May 2020 20:20:02 +0000

Mark Phippard wrote on Fri, 01 May 2020 18:26 +00:00:
> On Fri, May 1, 2020 at 2:17 PM Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> > I'm not asking for special treatment or for changing the policy. I'm
> > asking to clarify the policy for the general case of the period of time
> > immediately following a 1.(x+1).0 release, where the 1.x line was a
> > non-LTS release. (In this specific instance x+1 is an LTS release, but
> > that's a red herring.)
> The way I read and understood the policy the support is time based. A
> regular release is supported for 6 months from its initial release date
> or until the next release is available. If the next release came out 5
> months later then it would still get 6 months of support. If the next
> release came out 9 months later then it would get 9 months of support.

Thanks for clarifying this. That's my understanding too.

> 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.


(And again, this has nothing to do with 1.14 being LTS. It's been an
issue since the first time a 6-month-support minor line was obsoleted
by a newer minor line.)
Received on 2020-05-01 22:20:37 CEST

This is an archived mail posted to the Subversion Dev mailing list.