Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <2FDF5A97-DC47-4589-88D7-18655D10F8C6@effectivemachines.com>
References: <CAPz5eN7uUTAxNOUimao+hzx0hjwzVfZZz=vQE4PCVjimu8SSVQ@mail.gmail.com>
 <613605965.12351946.1470842058395.JavaMail.yahoo@mail.yahoo.com>
 <1470847185717.28914@hortonworks.com> <CAPz5eN6JVis5tKkVoPv1n=Low64AYOnMBU6w35tn31qDZWW6YA@mail.gmail.com>
 <1470920528790.43548@hortonworks.com> <1D457905-E069-4DD0-AE8A-CDB38EECC47D@effectivemachines.com>
 <1470928427902.19947@hortonworks.com> <2FDF5A97-DC47-4589-88D7-18655D10F8C6@effectivemachines.com>
From: Karthik Kambatla <kasha@cloudera.com>
Date: Thu, 11 Aug 2016 13:03:36 -0700
Message-ID: <CALwhT97q2j8wfwAJsV=jq6GsYQOYFG3Sqe5JWThHiXRntmAZ1Q@mail.gmail.com>
Subject: Re: [Release thread] 2.6.5 release activities
Cc: "common-dev@hadoop.apache.org" <common-dev@hadoop.apache.org>,
	"hdfs-dev@hadoop.apache.org" <hdfs-dev@hadoop.apache.org>,
	"mapreduce-dev@hadoop.apache.org" <mapreduce-dev@hadoop.apache.org>,
	"yarn-dev@hadoop.apache.org" <yarn-dev@hadoop.apache.org>
Content-Type: multipart/alternative; boundary=001a113f73d8e2a3c80539d14233
archived-at: Thu, 11 Aug 2016 20:03:44 -0000

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

Since there is sufficient interest in 2.6.5, we should probably do it. All
the reasons Allen outlines make sense.

That said, Junping brings up a very important point that we should think of
for future releases. For a new user or a user that does not directly
contribute to the project, more stable releases make it hard to pick from.

As Chris T mentioned, the notion of EOL for our releases seems like a good
idea. However, to come up with any EOLs, we need to have some sort of
cadence for the releases. While this is hard for major releases (big bang,
potentially incompatible features), it should be doable for minor releases.

How do people feel about doing a minor release every 6 months, with
follow-up maintenance releases every 2 months until the next minor and as
needed after that? That way, we could EOL a minor release a year after its
initial release? In the future, we could consider shrinking this window. In
addition to the EOL, this also makes our releases a little more predictable
for both users and vendors. Note that 2.6.0 went out almost 2 years ago and
we haven't had a new minor release in 14 months. I am happy to start
another DISCUSS thread around this if people think it is useful.

Thanks
Karthik

On Thu, Aug 11, 2016 at 12:50 PM, Allen Wittenauer <aw@effectivemachines.com
> wrote:

>
> > On Aug 11, 2016, at 8:10 AM, Junping Du <jdu@hortonworks.com> wrote:
> >
> > Allen, to be clear, I am not against any branch release effort here.
> However,
>
>                 "I'm not an X but.... "
>
> > as RM for previous releases 2.6.3 and 2.6.4, I feel to have
> responsibility to take care branch-2.6 together with other RMs (Vinod and
> Sangjin) on this branch and understand current gap - especially, to get
> consensus from community on the future plan for 2.6.x.
> > Our bylaw give us freedom for anyone to do release effort, but our bylaw
> doesn't stop our rights for reasonable question/concern on any release
> plan. As you mentioned below, people can potentially fire up branch-1
> release effort. But if you call a release plan tomorrow for branch-1, I
> cannot imagine nobody will question on that effort. Isn't it?
>
>                 From previous discussions I've seen around releases, I
> think it would depend upon which employee from which vendor raised the
> question.
>
> > Let's keep discussions on releasing 2.6.5 more technical. IMO, to make
> 2.6.5 release more reasonable, shouldn't we check following questions first?
> > 1. Do we have any significant issues that should land on 2.6.5 comparing
> with 2.6.4?
> > 2. If so, any technical reasons (like: upgrade is not smoothly,
> performance downgrade, incompatibility with downstream projects, etc.) to
> stop our users to move from 2.6.4 to 2.7.2/2.7.3?
> > I believe having good answer on these questions can make our release
> plan more reasonable to the whole community. More thoughts?
>
>         I think these questions are moot though:
>
> * Hadoop 2.6 is the last release to support JDK6.   That sort of ends any
> questions around moving to 2.7.
>
> * There are always bugs in software that can benefit from getting fixes.
> Given the JDK6 issue, yes, of course there are reasons why someone may want
> a 2.6.5.
>
> * If a company/vendor is willing to fund people to work on a release, I'd
> much rather they do that work in the ASF than off on their own somewhere.
> This way the community as a whole benefits.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
>
>

--001a113f73d8e2a3c80539d14233--