If every other release is a bug fix release, would the versioning go: 3.1.0 <-- feature release 3.1.1 <-- bug fix release
Eventually it seems like it might be possible to be able to push out a bug fix release more frequently than once a month? On Wed, Mar 18, 2015 at 7:59 AM Josh McKenzie <josh.mcken...@datastax.com> wrote: > +1 > > On Wed, Mar 18, 2015 at 7:54 AM, Jake Luciani <jak...@gmail.com> wrote: > > > +1 > > > > On Tue, Mar 17, 2015 at 5:06 PM, Jonathan Ellis <jbel...@gmail.com> > wrote: > > > Cassandra 2.1 was released in September, which means that if we were on > > > track with our stated goal of six month releases, 3.0 would be done > about > > > now. Instead, we haven't even delivered a beta. The immediate cause > > this > > > time is blocking for 8099 > > > <https://issues.apache.org/jira/browse/CASSANDRA-8099>, but the > reality > > is > > > that nobody should really be surprised. Something always comes up -- > > we've > > > averaged about nine months since 1.0, with 2.1 taking an entire year. > > > > > > We could make theory align with reality by acknowledging, "if nine > months > > > is our 'natural' release schedule, then so be it." But I think we can > do > > > better. > > > > > > Broadly speaking, we have two constituencies with Cassandra releases: > > > > > > First, we have the users who are building or porting an application on > > > Cassandra. These users want the newest features to make their job > > easier. > > > If 2.1.0 has a few bugs, it's not the end of the world. They have time > > to > > > wait for 2.1.x to stabilize while they write their code. They would > like > > > to see us deliver on our six month schedule or even faster. > > > > > > Second, we have the users who have an application in production. These > > > users, or their bosses, want Cassandra to be as stable as possible. > > > Assuming they deploy on a stable release like 2.0.12, they don't want > to > > > touch it. They would like to see us release *less* often. (Because > that > > > means they have to do less upgrades while remaining in our backwards > > > compatibility window.) > > > > > > With our current "big release every X months" model, these users' needs > > are > > > in tension. > > > > > > We discussed this six months ago, and ended up with this: > > > > > > What if we tried a [four month] release cycle, BUT we would guarantee > > that > > >> you could do a rolling upgrade until we bump the supermajor version? > So > > 2.0 > > >> could upgrade to 3.0 without having to go through 2.1. (But to go to > > 3.1 > > >> or 4.0 you would have to go through 3.0.) > > >> > > > > > > Crucially, I added > > > > > > Whether this is reasonable depends on how fast we can stabilize > releases. > > >> 2.1.0 will be a good test of this. > > >> > > > > > > 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. > > > > > > A big reason that it takes us so long to stabilize new releases now is > > > that, because our major release cycle is so long, it’s super tempting > to > > > slip in “just one” new feature into bugfix releases, and I’m as guilty > of > > > that as anyone. > > > > > > For similar reasons, it’s difficult to do a meaningful freeze with big > > > feature releases. A look at 3.0 shows why: we have 8099 coming, but we > > > also have significant work done (but not finished) on 6230, 7970, 6696, > > and > > > 6477, all of which are meaningful improvements that address > demonstrated > > > user pain. So if we keep doing what we’ve been doing, our choices are > to > > > either delay 3.0 further while we finish and stabilize these, or we > wait > > > nine months to a year for the next release. Either way, one of our > > > constituencies gets disappointed. > > > > > > 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. > > > > > > So here is my proposal for 3.0: > > > > > > We’re just about ready to start serious review of 8099. When that’s > > done, > > > we branch 3.0 and cut a beta and then release candidates. Whatever > isn’t > > > done by then, has to wait; unlike prior betas, we will only accept bug > > > fixes into 3.0 after branching. > > > > > > One month after 3.0, we will ship 3.1 (with new features). At the same > > > time, we will branch 3.2. New features in trunk will go into 3.3. The > > 3.2 > > > branch will only get bug fixes. We will maintain backwards > compatibility > > > for all of 3.x; eventually (no less than a year) we will pick a release > > to > > > be 4.0, and drop deprecated features and old backwards compatibilities. > > > Otherwise there will be nothing special about the 4.0 designation. > (Note > > > that with an “odd releases have new features, even releases only have > bug > > > fixes” policy, 4.0 will actually be *more* stable than 3.11.) > > > > > > Larger features can continue to be developed in separate branches, the > > way > > > 8099 is being worked on today, and committed to trunk when ready. So > > this > > > is not saying that we are limited only to features we can build in a > > single > > > month. > > > > > > Some things will have to change with our dev process, for the better. > In > > > particular, with one month to commit new features, we don’t have room > for > > > committing sloppy work and stabilizing it later. Trunk has to be > stable > > at > > > all times. I asked Ariel Weisberg to put together his thoughts > > separately > > > on what worked for his team at VoltDB, and how we can apply that to > > > Cassandra -- see his email from Friday <http://bit.ly/1MHaOKX>. > (TLDR: > > > Redefine “done” to include automated tests. Infrastructure to run > tests > > > against github branches before merging to trunk. A new test harness > for > > > long-running regression tests.) > > > > > > 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. > > > > > > This won’t be an entirely smooth transition. In particular, you will > > have > > > noticed that 3.1 will get more than a month’s worth of new features > while > > > we stabilize 3.0 as the last of the old way of doing things, so some > > > patience is in order as we try this out. By 3.4 and 3.6 later this > year > > we > > > should have a good idea if this is working, and we can make adjustments > > as > > > warranted. > > > > > > -- > > > Jonathan Ellis > > > Project Chair, Apache Cassandra > > > co-founder, http://www.datastax.com > > > @spyced > > > > > > > > -- > > http://twitter.com/tjake > > > > > > -- > Joshua McKenzie > DataStax -- The Apache Cassandra Company >
