>
What is the difference between 3.0.x series and 3.1?
> - trunk represents the upcoming cassandra-3.2 release (fixes from 3.1 and
> new features)
>
> --
> AY
--
Thanks,
Phil Yang
> > >
> > >
> > > * - Extend 2.1.x series and 2.2.x until 4.0, but skip 3.0.x
> stabilization
> > > series in favor of tick-tock 3.x- Extend 2.1.x series until 4.0, but
> stop
> > > 2.2.x when 3.0 ships in favor of developing 3.0.x insteadThoughts?*
> > >
> > > --
> > > Jonathan Ellis
> > > Project Chair, Apache Cassandra
> > > co-founder, http://www.datastax.com
> > > @spyced
>
--
Thanks,
Phil Yang
tained for at least a year
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>
--
Thanks,
Phil Yang
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
> > >>>>>
> > >>>>
> > >>>
> > >
> >
> >
>
--
Thanks,
Phil Yang
ld we
make each release more frequently? Or we may make a rule to decide if we
need release a new version? For example: "If the latest version was
released two weeks ago, or after the latest version we have already
resolved 20 issues, we should release a new minor version".
--
Thanks,
Phil Yang
