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

Re: officially retire 1.9?

From: Stefan Sperling <stsp_at_elego.de>
Date: Fri, 16 Aug 2019 08:15:41 +0200

On Mon, Aug 12, 2019 at 03:40:50PM +0100, Julian Foad wrote:
> Branko Čibej wrote:
> > On 05.08.2019 20:27, Stefan Sperling wrote:
> > > Subversion 1.9.0 is 4 years old today (release on August 5 2015).
> > > http://subversion.apache.org/roadmap.html#release-planning says that
> > > each LTS release is supported for 4 years.
> > >
> > > Julian said on IRC that perhaps we decided to support 2 LTS releases
> > > for either 4 years or until another LTS release appears.
> > > Which means 1.9 would still be supported until 1.14 is released.
>
> We documented "If a release takes longer than planned, we will extend the
> support periods of the previous releases accordingly." [1] I intended this
> to mean we would continue to apply the spirit of our historical support for
> "the current and the previous" releases for the newly designated "LTS"
> releases.
>
> I acknowledge that's not totally clear, and all our decisions can be
> reviewed.

Thanks for clarifying. Indeed, I missed this.

> Let's take a moment to remind other readers that "unsupported" means we
> don't expect or intend to make another release; it does not mean there is
> absolutely no possibility of a further release if there should be sufficient
> justification for the effort required.

Right.

> Conversely, we can "softly" reduce support for it: we are not obliged to
> backport any particular fixes or make any particular number of releases.
>
> I will say that in recently releasing 1.12.2, 1.10.6, and 1.9.12, the amount
> of work I had to do for three release lines compared to two was much less
> than proportional.

But the amount of work involved in everyone else running tests and signing
releases must also be considered. We barely made the required signature count
for our last 3 releases. Focussing our volunteer resources on releases that
are actually used by Debian and Red Hat (as reference platforms that usually
ship our "oldest" releases) seems fair.

> So I vote for softly reducing the support effort while leaving it documented
> as "supported".

That's fine with me. It would more or less amount to the same thing :)
We have had "security and data corruption fixes only" backport guidelines
in the past. I'd suggest we could apply this to 1.9.
Received on 2019-08-16 08:15:52 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.