+1 (although I'm dreading the export from old sstables into new sstables, any ideas on how fast that might be?, and I guess any idea if a tool for doing this will be provided, or is it sstable2json and json2sstable?)
On Wed, Feb 17, 2010 at 07:56:27PM -0800, Chris Goffinet wrote: > +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 > -- ------------------------------------------------------------------------ Anthony Molinaro <antho...@alumni.caltech.edu>
