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 <st...@duboce.net> wrote: > On Wed, Apr 7, 2010 at 11:34 AM, Todd Lipcon <t...@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 >> >
