Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
Sender: sjlee0@gmail.com
In-Reply-To: <CAGB5D2Zar12Qxp61wWsipt4SODzKWqOn8g32edhvmj6VhWuUcQ@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> <CAGB5D2Zar12Qxp61wWsipt4SODzKWqOn8g32edhvmj6VhWuUcQ@mail.gmail.com>
From: Sangjin Lee <sjlee@apache.org>
Date: Fri, 4 Nov 2016 10:33:31 -0700
Message-ID: <CADbBEnu_xQEiU2Fu0BAcyG_op3AgRq_Nc_snSdfF606ya_2DiQ@mail.gmail.com>
Subject: Re: [DISCUSS] Release cadence and EOL
To: Andrew Wang <andrew.wang@cloudera.com>
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=001a113ed15cdb4e8e05407d1305
archived-at: Fri, 04 Nov 2016 17:34:09 -0000

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

Thanks for your thoughts and more data points Andrew.

I share your concern that the proposal may be more aggressive than what we
have been able to accomplish so far. I'd like to hear from the community
what is a desirable release cadence which is still within the realm of the
possible.

The EOL policy can also be a bit of a forcing function. By having a defined
EOL, hopefully it would prod the community to move faster with releases. Of
course, automating releases and testing should help.


On Tue, Nov 1, 2016 at 4:31 PM, Andrew Wang <andrew.wang@cloudera.com>
wrote:

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

--001a113ed15cdb4e8e05407d1305--