Thanks for sharing your opinion.
On Thu, Apr 25, 2013 at 8:28 AM, Robert Evans <[EMAIL PROTECTED]> wrote:
> I like the idea. +1
> I would just make a few tweaks to it, but I am not married to the tweaks
> and would be happy to adopt the proposal as is. I would prefer a trunk
> release every quarter. I am fine if a release manager wants to release
> more often, but I think a regular release cadence makes it simpler for
> downstream projects and customers to plan for testing and integrating with
> these new releases.
> I would also like to have a formal process for adopting long term
> stabilization branches and for retiring them.
What do you mean by that?
Branches are adopted if a group of people decides to use and support
one. Just the way it happened with branch 0.23, but did not with
0.21 or 0.22. The latter naturally retired, not to say it was a lost cause.
I don't think there is a way to tell people to use or not one branch or
So the purpose of the community as I see it is to create the ground
for stabilizing the releases we produce.
> The problem with branch-0.23
> is that it really is just being stabilized by one group. This in and of
> itself isn't bad but if the majority of the community is on the same base
> it will stabilize more quickly, and downstream projects/customers can know
> that for the next N-months this branch will be available and receive
> bug/security fixes. At the end of N-months the community can decide to
> continue supporting the branch for another period of time or to stop.
> That way customers can have confidence that when they adopt a branch they
> know how long it will be around for.
True. Good or bad this is how the community works.
Anybody can build and propose a release or a change.
So as anybody can drop a feature in the middle of implementation and
never come back. Don't even need a vote on that.
That is why we should develop them in branches and release upon completion.
So that our customers could be at least sure that the branch they picked up
is not going to change and they can contribute to its stabilization as they
It is really great that Yahoo team (with you as RM) yet again helped
Hadoop move forward. Not talking about 0.23 only here.
> Also I would not really want 0.23.7 to be marked as the latest stable
> release, unless
Not sure I understood. Are you saying 0.23.7 could be marked stable
under the three conditions. What are they?
> 1) the community decides that we will maintain it going forward for at
> least 6 to 12 more months
Are you asking for help or are you concerned that 0.23 branch will
somehow disappear? Don't think the latter is possible.
Look at branch 1, previously known as 0.20. It's been there for
> 2) we have a nice long explanation about why 0.23.X is actually a higher
> release than 1.X is and
I know people are confused about version numbers.
> 3) 0.23 gets the changes to the YARN APIs back ported to it.
Interesting, so you want your customers to keep updating their
applications to adapt to new APIs? Usually it is the other way around.
> The 1.X line has support from several organizations to maintain it for at
> least the next year or so and there is no need to confuse people about
> version numbering. (Putting on my Yahoo! hat now) we at Yahoo! are still
> trying to figure out the exact time frame as to when and how we can move
> off of 0.23 and on to 2.0. I don't know if we are going to be supporting
> 0.23 beyond critical bug fixes nor really for how long we would be doing
> that. It will probably be for the next 6 months or so, but I really don't
> know. It depends on how fast 2.0 becomes stable.
I hope that moving 0.23 to stable will accelerate stabilization of branch 2.
> On 4/24/13 10:17 PM, "Konstantin Shvachko" <[EMAIL PROTECTED]> wrote:
> > Hi everybody,
> >There was and is a number of discussions about Hadoop version
> >compatibility, feature porting, stability. I think that many problems of