hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karthik Kambatla <ka...@cloudera.com>
Subject Re: [DISCUSS] Release cadence and EOL
Date Wed, 11 Jan 2017 19:05:26 GMT
I am certainly in favor of doing a vote for the same.

Along with that, we should likely make some progress on the logistic issues
with doing a release that Andrew raised.

On Tue, Jan 3, 2017 at 4:06 PM, Sangjin Lee <sjlee@apache.org> wrote:

> Happy new year!
>
> I think this topic has aged quite a bit in the discussion thread. Should
> we take it to a vote? Do we need additional discussions?
>
> Regards,
> Sangjin
>
> On Wed, Nov 9, 2016 at 11:11 PM, Karthik Kambatla <kasha@cloudera.com>
> wrote:
>
>> Fair points, Sangjin and Andrew.
>>
>> To get the ball rolling on this, I am willing to try the proposed policy.
>>
>> On Fri, Nov 4, 2016 at 12:09 PM, Andrew Wang <andrew.wang@cloudera.com>
>> wrote:
>>
>> > I'm certainly willing to try this policy. There's definitely room for
>> > improvement when it comes to streamlining the release process. The
>> > create-release script that Allen wrote helps, but there are still a lot
>> of
>> > manual steps in HowToRelease for staging and publishing a release.
>> >
>> > Another perennial problem is reconciling git log with the changes and
>> > release notes and JIRA information. I think each RM has written their
>> own
>> > scripts for this, but it could probably be automated into a Jenkins
>> report.
>> >
>> > And the final problem is that branches are often not in a releasable
>> > state. This is because we don't have any upstream integration testing.
>> For
>> > instance, testing with 3.0.0-alpha1 has found a number of latent
>> > incompatibilities in the 2.8.0 branch. If we want to meaningfully speed
>> up
>> > the minor release cycle, continuous integration testing is a must.
>> >
>> > Best,
>> > Andrew
>> >
>> > On Fri, Nov 4, 2016 at 10:33 AM, Sangjin Lee <sjlee@apache.org> wrote:
>> >
>> >> 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.
>> >>> > >
>> >>> > >
>> >>> > >
>> >>> >
>> >>>
>> >>
>> >>
>> >
>>
>
>

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