Mark Phippard wrote on Fri, 01 May 2020 11:49 -0400:
> On Thu, Apr 30, 2020 at 12:47 PM Daniel Shahaf <d.s_at_daniel.shahaf.name>
> wrote:
>
> > danielsh_at_apache.org wrote on Thu, 30 Apr 2020 16:21 -0000:
> > > +++ subversion/site/publish/docs/release-notes/1.14.html Thu Apr 30
> > 16:21:48 2020
> > > @@ -1330,6 +1330,20 @@ if they occur.</p>
> > > +<div class="h3" id="svn-1.13-deprecation">
> > > +<h3>Subversion 1.13.x is end of life
> > > + <a class="sectionlink" href="#svn-1.13-deprecation"
> > > + title="Link to this section">¶</a>
> > > +</h3>
> > > +
> > > +<p>The Subversion 1.13.x line is end of life (<abbr title="End Of
> > Life">EOL</abbr>).
> > > +This doesn't mean that your 1.13 installation is doomed; if it works
> > > +well and is all you need, that's fine. "End of life" just means we've
> > > +stopped accepting bug reports against 1.13.x versions, and will not
> > > +make any more 1.13.x releases.</p>
> >
> > I just copied the text we use for 1.9, but there's a distinction: users
> > of 1.9 have had time to upgrade to 1.10 before 1.14.0 becomes GA,
> > whereas users of 1.13 have not. So, should we promise some sort of
> > grace period for users of 1.13.x — i.e., a period following the release
> > of 1.14.0 during which we'll still fix security bugs in 1.13.0?
> >
> > Granted, 1.13 was a regular release and was only promised to be
> > supported for six months (or until 1.14.0) in the first place, so the
> > grace period needn't be long.
> >
>
> My recollection is that we gave 1.9 special treatment because 1.10 was the
> first release with the new LTS policy in place. So we said we would handle
> 1.9 the same way we would have prior to the new policy. I do not see any
> reason to give 1.13 special treatment. We created the LTS policy and we
> should plan on sticking to it. It is not like we do not have the option of
> doing whatever we want when and if a security issue actually crops up.
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.)
If we want to leave it as unspecified, I'll defer to consensus. And,
incidentally, I think we can likewise leave unspecified the policy for
which minor versions of Python 3 we'll support, thereby resolving
a (user-facing) TODO in the 1.14 release notes.
Cheers,
Daniel
Received on 2020-05-01 20:17:14 CEST