We've been working on the 'ooh, shiny' approach to upgrading. Basically, once we see a new feature which will make life easier, better or just give us an excuse to play we start the process of adoption.
Once we've managed to get our unit tests to pass, and updated our internal process documentation we then roll it out to our customers. We've never had a roll back, and each upgrade has pretty much been a dump -> install -> seed, and off we go. Hats of to the cassandra chaps, it just keeps getting better. -- Jools Enticknap Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Friday, 20 April 2012 at 19:33, Dave Brosius wrote: > +1 > > is there any stats on customer adoption of new versions? I'd wonder if > people generally move to new versions every 4 months, as that could be > potentially painful for them as well. Given the amount of questions > regarding older versions still percolating, i'd guess the answer is > they'd be ok with it too. > > > > On 04/20/2012 01:57 PM, Jonathan Ellis wrote: > > After the 0.7 release we decided to shoot for a fixed four-month > > release cycle. I think now is a good time to re-evaluate this, and > > possibly change to target a six month cycle: > > > > - Speaking for DataStax, about half our time is spent on maintenance. > > Given this, a 3 month window just isn't much time to work on some of > > the larger features we have planned. > > > > - Most of the schedule slip has been in our post-freeze QA period. A > > six month cycle would allow a more realistic 6 or even 8 weeks of QA, > > while still expanding the dev window. > > > > - Cassandra has matured enough that there is less low-hanging fruit to > > pick; two potential upgrades per year feels better matched to that, > > than three. > > > > - The reality has been that 0.8, 1.0, and 1.1 took about 5, 5.5, and 6 > > months, respectively. So in a sense, officially making it a 6-month > > cycle would only be acknowledging reality anyway. > > > > Thoughts?
