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 >
