hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Lipcon <t...@cloudera.com>
Subject Re: Vote on 0.20.3.1
Date Wed, 07 Apr 2010 18:34:10 GMT
On Wed, Apr 7, 2010 at 11:21 AM, Stack <stack@duboce.net> wrote:

> On Tue, Apr 6, 2010 at 10:24 PM, Ryan Rawson <ryanobjc@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message