Short answer: yes. Longer answer, pasted from my reply to Jon Haddad elsewhere in the thread:
We are moving away from designating major releases like 3.0 as "special," other than as a marker of compatibility. In fact we are moving away from major releases entirely, with each release being a much smaller, digestible unit of change, and the ultimate goal of every even release being production-quality. This means that bugs won't pile up and compound each other. And bugs that do slip through will affect less users. As 3.x stabilizes, more people will try out the releases, yielding better quality, yielding even more people trying them out in a virtuous cycle. This won't just happen by wishing for it. I am very serious about investing the energy we would have spent on backporting fixes to a "stable" branch, into improving our QA process and test coverage. After a very short list of in-progress features that may not make the 3.0 cutoff (#6477, #6696 come to mind) I'm willing to virtually pause new feature development entirely to make this happen. On Tue, Apr 14, 2015 at 11:53 PM, Phil Yang <ud1...@gmail.com> wrote: > Hi Jonathan, > > How long will tick-tock releases will be maintained? Do users have to > upgrade to a new even release with new features to fix the bugs in an older > even release? > > 2015-04-14 6:28 GMT+08:00 Jonathan Ellis <jbel...@gmail.com>: > > > On Tue, Mar 17, 2015 at 4:06 PM, Jonathan Ellis <jbel...@gmail.com> > wrote: > > > > > > > > I’m optimistic that as we improve our process this way, our even > releases > > > will become increasingly stable. If so, we can skip sub-minor releases > > > (3.2.x) entirely, and focus on keeping the release train moving. In > the > > > meantime, we will continue delivering 2.1.x stability releases. > > > > > > > The weak point of this plan is the transition from the "big release" > > development methodology culminating in 3.0, to the monthly tick-tock > > releases. Since 3.0 needs to go through a beta/release candidate phase, > > during which we're going to be serious about not adding new features, > that > > means that 3.1 will come with multiple months worth of features, so right > > off the bat we're starting from a disadvantage from a stability > standpoint. > > > > Recognizing that it will take several months for the tick-tock releases > to > > stabilize, I would like to ship 3.0.x stability releases concurrently > with > > 3.y tick-tock releases. This should stabilize 3.0.x faster than > tick-tock, > > while at the same time hedging our bets such that if we assess tick-tock > in > > six months and decide it's not delivering on its goals, we're not six > > months behind in having a usable set of features that we shipped in 3.0. > > > > So, to summarize: > > > > - New features will *only* go into tick-tock releases. > > - Bug fixes will go into tick-tock releases and a 3.0.x branch, which > will > > be maintained for at least a year > > > > -- > > Jonathan Ellis > > Project Chair, Apache Cassandra > > co-founder, http://www.datastax.com > > @spyced > > > > > > -- > Thanks, > Phil Yang > -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced
