Re: officially retire 1.9?
Daniel Shahaf wrote: What's 1.9's new end-of-life date, then? Until what (past or future) date do we _commit_ to backporting critical fixes? The release date of the next LTS release. According to the currently planned release cycles, that will be v1.14 in April 2020. (It might be affected by the outcome of the discussion about stabilizing svn, in which Mark suggested we might want to re-think the release strategy.) - Julian
Re: officially retire 1.9?
Julian Foad wrote on Fri, 16 Aug 2019 09:47 +00:00: > Stefan Sperling wrote: > > [...] > 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. > > Sounds good to me. What's 1.9's new end-of-life date, then? Until what (past or future) date do we _commit_ to backporting critical fixes?
Re: officially retire 1.9?
Stefan Sperling wrote: [...] > 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. Sounds good to me. Thanks. - Julian
Re: officially retire 1.9?
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.
Re: officially retire 1.9?
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. But do we really want to continue supporting 1.9? You probably noticed that this question arose on users@. I promised we'll announce what we decide. For the record, I agree we can stop supporting 1.9. I'm not sure we should. 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. 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. So I vote for softly reducing the support effort while leaving it documented as "supported". - Julian [1] http://subversion.apache.org/roadmap.html#release-planning
Re: officially retire 1.9?
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. > > But do we really want to continue supporting 1.9? You probably noticed that this question arose on users@. I promised we'll announce what we decide. For the record, I agree we can stop supporting 1.9. -- Brane
Re: officially retire 1.9?
On Mon, Aug 5, 2019 at 2:27 PM Stefan Sperling wrote: > Those two operating systems have always been the ones shipping the > oldest possible SVN release, as far as I can remember. So if they don't > need Subversion 1.9, I don't see any reason for us to support it beyond > its 4 years lifetime promised on our web site. > Makes sense to me ... +1 -- Thanks Mark Phippard
officially retire 1.9?
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. But do we really want to continue supporting 1.9? Do we really want to support two LTS releases at once? I think this situation arose only because 1.9 got caught in the transition phase towards our new release planning guidelines. SVN 1.10 has been picked up by the latest Debian-stable release and also appears to be included in the upcoming CentOS 8 (which will match RHEL 8, as far as I know). Those two operating systems have always been the ones shipping the oldest possible SVN release, as far as I can remember. So if they don't need Subversion 1.9, I don't see any reason for us to support it beyond its 4 years lifetime promised on our web site.
