Mailing-List: contact yarn-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <CADbBEnuesEFi5SFQ2cgr6qQ71UjK-FOfosgu52SgxHRq8srAFg@mail.gmail.com>
References: <CALwhT95z03sMCj+21xEhAke609RhXvixrmb=d_Nu48F6SwyDpw@mail.gmail.com>
 <CADbBEnsVeUT106cREuFnjqfF_NNkXLoeXiDx2JT263kn_7TMAQ@mail.gmail.com>
 <CALwhT95SuRz-GpG06zcZ0BJMTfGQ_Ba5MKBbatmYxrpi=HJtbQ@mail.gmail.com> <CADbBEnuesEFi5SFQ2cgr6qQ71UjK-FOfosgu52SgxHRq8srAFg@mail.gmail.com>
From: Andrew Wang <andrew.wang@cloudera.com>
Date: Tue, 1 Nov 2016 16:31:51 -0700
Message-ID: <CAGB5D2Zar12Qxp61wWsipt4SODzKWqOn8g32edhvmj6VhWuUcQ@mail.gmail.com>
Subject: Re: [DISCUSS] Release cadence and EOL
To: Sangjin Lee <sjlee@apache.org>
Cc: Karthik Kambatla <kasha@cloudera.com>,
	"common-dev@hadoop.apache.org" <common-dev@hadoop.apache.org>,
	"hdfs-dev@hadoop.apache.org" <hdfs-dev@hadoop.apache.org>,
	"yarn-dev@hadoop.apache.org" <yarn-dev@hadoop.apache.org>,
	"mapreduce-dev@hadoop.apache.org" <mapreduce-dev@hadoop.apache.org>
Content-Type: multipart/alternative; boundary=e89a8fb1eae8dbbd75054045bbe9
archived-at: Tue, 01 Nov 2016 23:32:20 -0000

--e89a8fb1eae8dbbd75054045bbe9
Content-Type: text/plain; charset=UTF-8

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

--e89a8fb1eae8dbbd75054045bbe9--