On Wed, Apr 7, 2010 at 11:21 AM, Stack <st...@duboce.net> wrote: > On Tue, Apr 6, 2010 at 10:24 PM, Ryan Rawson <ryano...@gmail.com> wrote: > > I don't get it - why did we commit all those things to 0.20 branch if > > they are not suitable for the next release? > > > > If we did accidentally commit things that are not suitable for 0.20.4, > > then we should revert them asap and make a 0.20.4 release from branch. > > Branching your release branch is... not a good idea. > > > > I don't see any issue with branching a release branch. > > Regards 0.20.4, all in branch needs to make it into a release but the > proposed 0.20.4 is currently incomplete. The suggestion is that > meantime, make a release that leaves out the half-done stuff --tested > data durability, etc. -- and ship critical bug fixes only. >
I agree with Ryan that branching the release branch can get pretty confusing. I've only seen a version number like 0.20.3.1 once before, and that was for a completely botched release, where the .1 was a very very minor fix on top of the first release. In this case, even though there aren't any giant changes slated, there are changes that are large enough that it seems dishonest to call it a "doubly minor" release on top of 0.20.3. Regarding the bigger changes we have slated for 0.20 branch (eg durability fixes, 2248), why not just call it 0.21 at that point? We've already decided that future versions of HBase will be compatible with multiple versions of Hadoop, so we can add these major changes for 0.21 and then make 0.22 the next major release with replication, mvn, etc? -Todd > > My current dilemma is that I think a release should include HBASE-2322 > "deadlock between put and cacheflusher in 0.20 branch" -- this seemed > easy for me to trigger bulk uploading and IMO, a blocker -- but the > fix for the deadlock is HBASE-2248 "Provide new non-copy mechanism to > assure atomic reads in get and scan", a critical fix but a big change > in how Gets work. I'd like to ship with HBASE-2248 -- for one of the > reasons why, see comments in HBASE-2322 -- but I'd be uncomfortable > doing so w/o a bunch of testing first. > > What do you all think? > > St.Ack > -- Todd Lipcon Software Engineer, Cloudera