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.