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