+1 from Digg -Chris
On Feb 17, 2010, at 1:32 PM, Jonathan Ellis wrote: > We're looking at branching 0.6 today and starting 0.7 work. > > 0.6 shaped up to be a really nice follow-up to 0.5, where we improved > just about everything while keeping the upgrade path super easy. (We > changed the network around again, but no disk changes, so it's just > going to be shutdown-and-restart.) Client APIs are 100% compatible, > with the exception of get_key_range, which we had tagged as deprecated > in 0.5 for removal in the next release. > > So to recap recent history, we went from 0.4 to 0.5 to 0.6 without > major client level API changes. I think that is an excellent record > for where we were when we were releasing 0.4. > > 0.7 is probably going to be a little more painful, after which we hope > to have things stable for another few releases, at the least. > > Tickets currently tagged 0.7 are here: > > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310865&fixfor=12314533 > > They are a good mix of > - fundamental internals changes that we have been putting off so far > (#674, #16, and friends) > - stuff that we really really want to make ops better (#44) > - pie in the sky new features (#749) > - incremental improvements to what we already have > > The primary pain source from the client perspective is going to be the > internals changes, particularly moving row keys from String to byte[]. > But it's a change we've know need need to make and I think it's time > to bite the bullet. > > Also, if we were to execute on all the tickets there, 0.7 would be > this huge monster release that will take like 6 months to get out. i > think that's too long. Shipping is feature #1 at this stage, I'm > really scared of biting off too much and losing weeks or months to > that. > > So what I'd like to propose is making 0.7 primarily about the > internals changes and push for high-level queries in 0.8, where both > of those hit our usual ~3 month release cycle. I don't think it makes > sense to do those the other way around; introducing new APIs that we > already know we need to break just seems mean. :) > > -Jonathan
