hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jay Booth <jaybo...@gmail.com>
Subject Re: Release plans
Date Mon, 22 Feb 2010 04:55:09 GMT
Well, since someone has to get the ball rolling as far as release  
masters, I'll nominate Stack and/or someone hbase related for 0.21  
with the primary goal of being "soon"?  They get a big win from append  
and others will gain from the expanded mapreduce lib, better  
schedulers, etc. There are a lot of new features and some major  
changes (project split) already in the 0.21 branch, so IMO it's worth  
considering a release with minimal backports, rather than make binding  
decisions about 0.22 before 0.21 is even in the wild.

-Jay

PS sorry Stack

On Feb 20, 2010, at 5:04 PM, Stack <stack@duboce.net> wrote:

> On Fri, Feb 19, 2010 at 4:23 PM, Eli Collins <eli@cloudera.com> wrote:
>> Can we make a decision on basing 21 on the current branch and if it's
>> decided that 22 can't remove stuff that was in 20 we'll go back and  
>> do
>> the necessary additions on 21 and trunk? Suspect that decision will
>> take a lot more back and forth, but needs to conclude before 21 is
>> released.
>>
>
> Lets.
>
> Regards 0.21/current-branch release, as has been suggested above,
> first we need to figure the release master.  No release master, no
> release.  If we have a release master, then I suggest we vote on
> current branch being released as 0.21 as soon as the blockers are
> cleared.
>
> I don't think we need muddy the above vote with whether or not 0.21
> maintains API combatibility with 0.20.  IMO, it must (because Y! want
> to have the 0.20 API in place when January 2011 rolls around).  This
> makes 0.21 a "minor" release -- something we've not done before (For
> the record, I also had a misunderstanding that what we were doing up
> to this was major and patch only).  So, part of the release process
> would involve ensuring no removed deprecations, etc.
>
> As DC has been saying, this requirement that releases between now and
> January 2011 not change APIs makes 0.20 retroactively into a "major"
> release.  0.20 is the release where major shifted left in our
> versioning scheme and minor releases came into play.  0.21 and 0.22
> will be minor releases. Can we just acknowledge this fact, that there
> was a step at version 0.20, update the wiki around versioning -- its
> currently wrong anyways as Elis' points out -- and just move on?
> Going back and calling 0.20 a 1.0 seems more apt to create confusion
> and besides, I'm with Allen that hadoop 1.0 needs wire compatibility
> before the 1.0 can roll around.
>
> Thanks,
> St.Ack
> P.S. +1 on branching as soon as avro and security are in, etc.

Mime
View raw message