So, in light of Sandeep's point, I think I would prefer to do 0.3 now, and try to do a short 0.4 cycle with current trunk and
- the sstable redesign to address OOM problem - multitable support - patch to reduce logging impact so we look better in benchmarks :) - fsync fix - r/m old get_slice and rename get_slice_from to get_slice How does that sound? -Jonathan On Wed, Jun 3, 2009 at 4:59 PM, Jonathan Ellis <[email protected]> wrote: > You are right. Of course, there's no sense in making such a tool > harder to write than it needs to be. > > But I don't care that strongly since I won't be writing it. :P > > -Jonathan > > On Wed, Jun 3, 2009 at 4:53 PM, Sandeep Tata <[email protected]> wrote: >> Won't things like multi-table support break binary compatibility anyway? >> >> We might be stuck with having to write a tool that migrates from a 0.3 >> format to a 0.4 format. >> >> >> On Wed, Jun 3, 2009 at 2:44 PM, Jonathan Ellis <[email protected]> wrote: >>> The fix for 208 [1] is fairly invasive. should we >>> >>> (a) release another RC and do more testing before 0.3 final, or >>> (b) release 0.3 without these changes, and only add this fix to trunk? >>> >>> Although I see the 0.3 release primarily as a means to let people >>> start playing with the cassandra data model, I don't know that I want >>> to release it knowing that 0.4 is going to be binary-incompatible with >>> the 0.3 data files. So I'd be inclined towards (a). >>> >>> [1] https://issues.apache.org/jira/browse/CASSANDRA-208 >>> >>> -Jonathan >>> >> >
