O yea, and BGL4 is now green without any impending risks. Additionally, the other yellow projects LWR05 & MTV05 are on a path that will lead to green in coming weeks.
Thats All Folks -----Original Message----- From: Jonathan Ellis [mailto:jbel...@gmail.com] Sent: Wednesday, April 15, 2015 3:40 AM To: dev Subject: Re: 3.0 and the Cassandra release process 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
