Not so much worried about temporary breakages, but more about design decisions that are made to enhance cassandra at the cost of a data format change. So long as the policy here is to preserve backwards compatibility with the on disk storage format (possibly with an automatic conversion), even that shouldn't be a problem. I'll go ahead and follow commits/dev, but given my lack of experience with cassandra, I'm worried I might not be able to tell an important change from not, so it would be helpful if I knew if any more were planned for 0.7, or if an extra step was taken to announce these kinds of changes in one of the lists. Thanks,
Matt On Jun 11, 2010, at Fri Jun 11, 7:43 PM, Jonathan Ellis wrote: > If you're comfortable following comm...@cassandra.apache.org, it > should be pretty obvious which changes are going to break things > temporarily or require a commitlog drain. Otherwise, we recommend > sticking with the stable branch until a beta is released. > > On Fri, Jun 11, 2010 at 2:24 PM, Matthew Conway <m...@backupify.com> wrote: >> Hi All, >> >> I'd like to start using trunk for something real, but am concerned about >> stability of the data format. That is, will I be able to upgrade a running >> system to a newer version of trunk and eventually to the 7.0 release, or are >> there any changes planned to the format of the data stored on disk that >> would prevent this. I'm ok with having to do a full shutdown to do >> upgrades, or even some form of export/import (would prefer to avoid this), >> but obviously would need to know when the format has changed so I can do the >> right thing (announcements to mailing list?). What is the recommend >> procedure for dealing with upgrades? Thanks, >> >> Matt >> >> > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of Riptano, the source for professional Cassandra support > http://riptano.com
