On Thu, Jun 11, 2015 at 6:56 PM, Mohammed Guller <moham...@glassbeam.com> wrote:
> By that logic, 2.1.0 should have been somewhat as stable as 2.0.10 (the > last release of 2.0.x branch before 2.1.0). However, we found out that it > took almost 9 months for 2.1.x series to become stable and suitable for > production. Going by past history, I am worried that it may take the same > time for 2.2 to become stable. > The instability of initial point releases is a significant part of the motivation for the new release cadence.[1] If new versions continued to take just as long to be production ready, the new process would have failed at one of its major goals... For the record, I agree with the reasoning in the linked post and am cautiously optimistic about the effect it will have on the stability of released versions. :D =Rob [1] http://mail-archives.apache.org/mod_mbox/cassandra-dev/201503.mbox/%3CCALdd-zjAyiTbZksMeq2LxGwLF5LPhoi_4vsjy8JBHBRnsxH=8...@mail.gmail.com%3E " Unfortunately, even after DataStax hired half a dozen full-time test engineers, 2.1.0 continued the proud tradition of being unready for production use, with "wait for .5 before upgrading" once again looking like a good guideline. I’m starting to think that the entire model of “write a bunch of new features all at once and then try to stabilize it for release” is broken. We’ve been trying that for years and empirically speaking the evidence is that it just doesn’t work, either from a stability standpoint or even just shipping on time. ... So, I’d like to try something different. I think we were on the right track with shorter releases with more compatibility. But I’d like to throw in a twist. Intel cuts down on risk with a “tick-tock” schedule for new architectures and process shrinks instead of trying to do both at once. We can do something similar here: One month releases. Period. If it’s not done, it can wait. *Every other release only accepts bug fixes.* By itself, one-month releases are going to dramatically reduce the complexity of testing and debugging new releases -- and bugs that do slip past us will only affect a smaller percentage of users, avoiding the “big release has a bunch of bugs no one has seen before and pretty much everyone is hit by something” scenario. ***But by adding in the second rule, I think we have a real chance to make a quantum leap here: stable, production-ready releases every two months.*** " (*** emphasis mine)
