hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wang <andrew.w...@cloudera.com>
Subject Re: [DISCUSS] Release cadence and EOL
Date Tue, 01 Nov 2016 23:31:51 GMT
Thanks for pushing on this Sangjin. The proposal sounds reasonable.

However, for it to have teeth, we need to be *very* disciplined about the
release cadence. Looking at our release history, we've done 4 maintenance
releases in 2016 and no minor releases. 2015 had 4 maintenance and 1 minor
release. The proposal advocates for 12 maintenance releases and 2 minors
per year, or about 3.5x more releases than we've historically done. I think
achieving this will require significantly streamlining our release and
testing process.

For some data points, here are a few EOL lifecycles for some major
projects. They talk about support in terms of time (not number of
releases), and release on a cadence.

Ubuntu maintains LTS for 5 years:
https://www.ubuntu.com/info/release-end-of-life

Linux LTS kernels have EOLs ranging from 2 to 6 years, though it seems only
one has actually ever been EOL'd:
https://www.kernel.org/category/releases.html

Mesos supports minor releases for 6 months, with a new minor every 2 months:
http://mesos.apache.org/documentation/latest/versioning/

Eclipse maintains each minor for ~9 months before moving onto a new minor:
http://stackoverflow.com/questions/35997352/how-to-determine-end-of-life-for-eclipse-versions



On Fri, Oct 28, 2016 at 10:55 AM, Sangjin Lee <sjlee@apache.org> wrote:

> Reviving an old thread. I think we had a fairly concrete proposal on the
> table that we can vote for.
>
> The proposal is a minor release on the latest major line every 6 months,
> and a maintenance release on a minor release (as there may be concurrently
> maintained minor releases) every 2 months.
>
> A minor release line is EOLed 2 years after it is first released or there
> are 2 newer minor releases, whichever is sooner. The community reserves the
> right to extend or shorten the life of a release line if there is a good
> reason to do so.
>
> Comments? Objections?
>
> Regards,
> Sangjin
>
>
> On Tue, Aug 23, 2016 at 9:33 AM, Karthik Kambatla <kasha@cloudera.com>
> wrote:
>
> >
> >> Here is just an idea to get started. How about "a minor release line is
> >> EOLed 2 years after it is released or there are 2 newer minor releases,
> >> whichever is sooner. The community reserves the right to extend or
> shorten
> >> the life of a release line if there is a good reason to do so."
> >>
> >>
> > Sounds reasonable, especially for our first commitment. For current
> > releases, this essentially means 2.6.x is maintained until Nov 2016 and
> Apr
> > 2017 if 2.8 and 2.9 are not released by those dates.
> >
> > IIUC EOL does two things - (1) eases the maintenance cost for developers
> > past EOL, and (2) indicates to the user when they must upgrade by. For
> the
> > latter, would users appreciate a specific timeline without any caveats
> for
> > number of subsequent minor releases?
> >
> > If we were to give folks a specific period for EOL for x.y.z, we should
> > plan on releasing at least x.y+1.1 by then. 2 years might be a good
> number
> > to start with given our current cadence, and adjusted in the future as
> > needed.
> >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message