hadoop-mapreduce-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinod Kumar Vavilapalli <vino...@apache.org>
Subject Re: Looking to a Hadoop 3 release
Date Sat, 23 Apr 2016 01:10:05 GMT

I’m proposing making a new 3.x release (as has been discussed in this thread) off today’s
trunk (instead of creating a fresh branch-3) and create a new trunk-incompt where incompatible
changes that we don’t want in 3.x go.

This is mainly to avoid repeating the “we are not releasing 3.x off trunk” issue when
we start thinking about 4.x or any such major release in the future.

We’ll do 2.8.x independently and later figure out if 2.9 is needed or not.


> On Apr 22, 2016, at 5:59 PM, Allen Wittenauer <aw@apache.org> wrote:
>> On Apr 22, 2016, at 5:38 PM, Vinod Kumar Vavilapalli <vinodkv@apache.org> wrote:
>> On an unrelated note, offline I was pitching to a bunch of contributors another idea
to deal with rotting trunk post 3.x: *Make 3.x releases off of trunk directly*.
>> What this gains us is that
>> - Trunk is always nearly stable or nearly ready for releases
>> - We no longer have some code lying around in some branch (today’s trunk) that
is not releasable because it gets mixed with other undesirable and incompatible changes.
>> - This needs to be coupled with more discipline on individual features - medium to
to large features are always worked upon in branches and get merged into trunk (and a nearing
release!) when they are ready
>> - All incompatible changes go into some sort of a trunk-incompat branch and stay
there till we accumulate enough of those to warrant another major release.
>> Thoughts?
> 	Unless I’m missing something, all this proposal does is (using today’s branch names)
effectively rename trunk to trunk-incompat and branch-2 to trunk.  I’m unclear how moving
"rotting trunk” to “rotting trunk-incompat” is really progress.

View raw message