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
