hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Rawson <ryano...@gmail.com>
Subject Re: Vote on 0.20.3.1
Date Wed, 07 Apr 2010 19:16:53 GMT
If we made a 3rd branch we now have 3 hbase versions with 3 distinct
code lineages.  Will we patch this new 0.20.4 version as bugs come up?
Or will there be a recommendation to move to a wholly new code line?
If branch isn't ready today, why will it be ready in 4 weeks?


On Wed, Apr 7, 2010 at 12:14 PM, Stack <stack@duboce.net> wrote:
> On Wed, Apr 7, 2010 at 11:34 AM, Todd Lipcon <todd@cloudera.com> wrote:
>> ...
>> 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.
>>
>
> I should have been clearer.  I was referring to the physical branch in
> svn distinct from what we call the release.
>
> The consensus seemed to be going in the direction of calling the
> (branch of a branch) release 0.20.4 rather than 0.20.3.1 as a branch
> of a branch would usually imply.  I'd be fine with that.
>
> Up to this, if truth be told, our patch releases have been more than
> just bug fixes.  They've also included improvements and even new
> features.  This comes of our being strait-jacketed by our legacy tie
> to hadoop versioning (major and minor only IIUC, no space for patch
> number as in 0.20.2 is the major version 20 and the minor version 2)
> compounded by the lack of a release 0.21 to free up space for changes.
>  I liked 0.20.3.1. because it conveyed notion that this would be a
> patch release.... but I'm easy with what its called.
>
>
> St.Ack
>
>>
>>
>>>
>>> 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
View raw message