You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Aleksey Yeschenko <al...@apache.org> on 2015/11/09 17:35:49 UTC
cassandra-3.1 branch and new merge order
With 3.0.0 vote to be over soon, tick-tock is officially starting, and we are creating a new branch for cassandra-3.1 release.
New merge order: cassandra-2.2 -> cassandra-3.0 -> cassandra-3.1 -> trunk
- cassandra-3.0 branch is going to continue representing the 3.0.x series of releases (3.0 bugfixes only, as no new feature are supposed to go into 3.0.x release series)
- cassandra-3.1 branch will contain 3.0 bugfixes *only*
- trunk represents the upcoming cassandra-3.2 release (fixes from 3.1 and new features)
--
AY
Re: cassandra-3.1 branch and new merge order
Posted by Aleksey Yeschenko <al...@apache.org>.
3.0.1 and 3.1 will be identical this time around - that’s just a consequence of the transition. Starting with 3.0.2 and 3.2, however, the branches will diverge.
Skipping one or the other would look weird and break continuity, so we are still going to release both, despite them containing the same code.
--
AY
On 10 November 2015 at 12:14:19, Björn Hegerfors (bj0rn@spotify.com) wrote:
So there is no reason for an end-user to actually use 3.1, because it will
have the same features as 3.0.x, but won't be maintained? 3.0.x for high x
will be 3.1 plus more bug fixes. I'm not saying that's bad. Starting from
3.2, using any subsequent version will make sense.
On Tue, Nov 10, 2015 at 12:43 PM, Paulo Motta <pa...@gmail.com>
wrote:
> 3.0.x is an interim branch during the transition to the new tick tock
> release model, which will receive backported patches from bug-fix releases
> (3.1, 3.3, etc) that affect 3.0, so no new features will go into 3.0.x. So
> users can safely go to 3.0 before adopting tick tock, knowing they will be
> served with bug fixes in the 3.0.x series following the old model.
>
> 2015-11-09 22:12 GMT-08:00 Phil Yang <ud...@gmail.com>:
>
> > 2015-11-10 0:35 GMT+08:00 Aleksey Yeschenko <al...@apache.org>:
> > >
> > > - cassandra-3.0 branch is going to continue representing the 3.0.x
> series
> > > of releases (3.0 bugfixes only, as no new feature are supposed to go
> into
> > > 3.0.x release series)
> > > - cassandra-3.1 branch will contain 3.0 bugfixes *only*
> > >
> >
> > 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
> >
>
Re: cassandra-3.1 branch and new merge order
Posted by Björn Hegerfors <bj...@spotify.com>.
So there is no reason for an end-user to actually use 3.1, because it will
have the same features as 3.0.x, but won't be maintained? 3.0.x for high x
will be 3.1 plus more bug fixes. I'm not saying that's bad. Starting from
3.2, using any subsequent version will make sense.
On Tue, Nov 10, 2015 at 12:43 PM, Paulo Motta <pa...@gmail.com>
wrote:
> 3.0.x is an interim branch during the transition to the new tick tock
> release model, which will receive backported patches from bug-fix releases
> (3.1, 3.3, etc) that affect 3.0, so no new features will go into 3.0.x. So
> users can safely go to 3.0 before adopting tick tock, knowing they will be
> served with bug fixes in the 3.0.x series following the old model.
>
> 2015-11-09 22:12 GMT-08:00 Phil Yang <ud...@gmail.com>:
>
> > 2015-11-10 0:35 GMT+08:00 Aleksey Yeschenko <al...@apache.org>:
> > >
> > > - cassandra-3.0 branch is going to continue representing the 3.0.x
> series
> > > of releases (3.0 bugfixes only, as no new feature are supposed to go
> into
> > > 3.0.x release series)
> > > - cassandra-3.1 branch will contain 3.0 bugfixes *only*
> > >
> >
> > 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
> >
>
Re: cassandra-3.1 branch and new merge order
Posted by Paulo Motta <pa...@gmail.com>.
3.0.x is an interim branch during the transition to the new tick tock
release model, which will receive backported patches from bug-fix releases
(3.1, 3.3, etc) that affect 3.0, so no new features will go into 3.0.x. So
users can safely go to 3.0 before adopting tick tock, knowing they will be
served with bug fixes in the 3.0.x series following the old model.
2015-11-09 22:12 GMT-08:00 Phil Yang <ud...@gmail.com>:
> 2015-11-10 0:35 GMT+08:00 Aleksey Yeschenko <al...@apache.org>:
> >
> > - cassandra-3.0 branch is going to continue representing the 3.0.x series
> > of releases (3.0 bugfixes only, as no new feature are supposed to go into
> > 3.0.x release series)
> > - cassandra-3.1 branch will contain 3.0 bugfixes *only*
> >
>
> 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
>
Re: cassandra-3.1 branch and new merge order
Posted by Phil Yang <ud...@gmail.com>.
2015-11-10 0:35 GMT+08:00 Aleksey Yeschenko <al...@apache.org>:
>
> - cassandra-3.0 branch is going to continue representing the 3.0.x series
> of releases (3.0 bugfixes only, as no new feature are supposed to go into
> 3.0.x release series)
> - cassandra-3.1 branch will contain 3.0 bugfixes *only*
>
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
Re: cassandra-3.1 branch and new merge order
Posted by Ariel Weisberg <ar...@weisberg.ws>.
Hi,
What I had thought we were going to do was branch for a feature release
every two months and then backport fixes to the last feature release (or
prior ones) as desired.
So in terms of extra merge effort you only have to backport fixes, and
if we solved the release quality issues this is something that is very
little work. Even if we don't we only have to backport a months worth of
fixes (although I would advocate making it two months). If we do a
feature release every two months that gives us two months to put
together a bug fix release for it without falling behind or supporting
multiple older releases.
I am pretty confident that a month is not enough time to find and fix
the bugs in a release. Not the way we currently operate where activities
are unsynchronized and we don't make an effort to get stuff to "done"
quickly as a default. Instead we opt to have a lot of stuff in flight to
hide the latency of getting things to "done". That is also a problem
when there are dependencies.
TL;DR Even minor stuff stretches out to multiple months.
Another thing that came up is how the release schedule impacts
development work. There were some voices (can't recall who) who thought
that the month after a feature release would only contain bug fix work.
I don't think that makes much sense since you won't even necessarily
know what all the bugs are and you can't leave developers idle waiting
for bugs to come in.
I think we should scheduled feature work and as bugs come in do them
first. I think we should always be doing bugs first and that's how I
schedule my time (actually review, bugs, then new work). If you don't
connect the backpressure from bugs to the rate at which you do new work
you will always end up falling behind or rubber banding and not get the
benefits of passing CI.
Ariel
On Mon, Nov 9, 2015, at 12:23 PM, Jake Luciani wrote:
> I don't think there's anything wrong with it. I just think it's not
> needed.
>
> - The max someone would wait is 4 weeks and in my mind the feature writer
> is the best person to make the changes to merge the code to the latest
> version. Vs an unrelated change that may be improperly merged.
> - Today for every change we make we must manually merge on commit every
> time which is error prone, this goes away with a single branch.
> - We historically care about tests in the latest release branch. We've
> never done a great job fixing issues in the trunk when they happen (look
> at
> cassci trunk vs 3.0 today). So it's not like we gain anything by keeping
> 2
> branches there.
> - This keeps our testing focus on the task at hand so we dedicate our
> testing time in a given month to the changes of that release and don't
> need
> any parallel runs for features.
>
>
>
> On Mon, Nov 9, 2015 at 12:06 PM, Jonathan Ellis <jb...@gmail.com>
> wrote:
>
> > I'm not a huge fan of leaving features to rot unmerged for a couple
> > months. What is wrong with "new features go to trunk, stable branches get
> > forked at release?"
> >
> > On Mon, Nov 9, 2015 at 10:54 AM, Jake Luciani <ja...@gmail.com> wrote:
> >
> > > Looking back at the tick-tock email chain we never really discussed this.
> > >
> > > Rather than having 3.1 and trunk I think we should have just trunk.
> > >
> > > I'd rather not let features sit in a branch with bugfixes going on top
> > that
> > > can decay.
> > > They should be merged in when it's time to merge features for 3.even,
> > post
> > > 3.odd.
> > >
> > > I know we have features in trunk today that aren't in 3.0 and we probably
> > > shouldn't have done that.
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Nov 9, 2015 at 11:35 AM, Aleksey Yeschenko <al...@apache.org>
> > > wrote:
> > >
> > > > With 3.0.0 vote to be over soon, tick-tock is officially starting, and
> > we
> > > > are creating a new branch for cassandra-3.1 release.
> > > >
> > > > New merge order: cassandra-2.2 -> cassandra-3.0 -> cassandra-3.1 ->
> > trunk
> > > >
> > > > - cassandra-3.0 branch is going to continue representing the 3.0.x
> > series
> > > > of releases (3.0 bugfixes only, as no new feature are supposed to go
> > into
> > > > 3.0.x release series)
> > > > - cassandra-3.1 branch will contain 3.0 bugfixes *only*
> > > > - trunk represents the upcoming cassandra-3.2 release (fixes from 3.1
> > and
> > > > new features)
> > > >
> > > > --
> > > > AY
> > >
> > >
> > >
> > >
> > > --
> > > http://twitter.com/tjake
> > >
> >
> >
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder, http://www.datastax.com
> > @spyced
> >
>
>
>
> --
> http://twitter.com/tjake
Re: cassandra-3.1 branch and new merge order
Posted by Jake Luciani <ja...@gmail.com>.
I don't think there's anything wrong with it. I just think it's not needed.
- The max someone would wait is 4 weeks and in my mind the feature writer
is the best person to make the changes to merge the code to the latest
version. Vs an unrelated change that may be improperly merged.
- Today for every change we make we must manually merge on commit every
time which is error prone, this goes away with a single branch.
- We historically care about tests in the latest release branch. We've
never done a great job fixing issues in the trunk when they happen (look at
cassci trunk vs 3.0 today). So it's not like we gain anything by keeping 2
branches there.
- This keeps our testing focus on the task at hand so we dedicate our
testing time in a given month to the changes of that release and don't need
any parallel runs for features.
On Mon, Nov 9, 2015 at 12:06 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> I'm not a huge fan of leaving features to rot unmerged for a couple
> months. What is wrong with "new features go to trunk, stable branches get
> forked at release?"
>
> On Mon, Nov 9, 2015 at 10:54 AM, Jake Luciani <ja...@gmail.com> wrote:
>
> > Looking back at the tick-tock email chain we never really discussed this.
> >
> > Rather than having 3.1 and trunk I think we should have just trunk.
> >
> > I'd rather not let features sit in a branch with bugfixes going on top
> that
> > can decay.
> > They should be merged in when it's time to merge features for 3.even,
> post
> > 3.odd.
> >
> > I know we have features in trunk today that aren't in 3.0 and we probably
> > shouldn't have done that.
> >
> >
> >
> >
> >
> >
> > On Mon, Nov 9, 2015 at 11:35 AM, Aleksey Yeschenko <al...@apache.org>
> > wrote:
> >
> > > With 3.0.0 vote to be over soon, tick-tock is officially starting, and
> we
> > > are creating a new branch for cassandra-3.1 release.
> > >
> > > New merge order: cassandra-2.2 -> cassandra-3.0 -> cassandra-3.1 ->
> trunk
> > >
> > > - cassandra-3.0 branch is going to continue representing the 3.0.x
> series
> > > of releases (3.0 bugfixes only, as no new feature are supposed to go
> into
> > > 3.0.x release series)
> > > - cassandra-3.1 branch will contain 3.0 bugfixes *only*
> > > - trunk represents the upcoming cassandra-3.2 release (fixes from 3.1
> and
> > > new features)
> > >
> > > --
> > > AY
> >
> >
> >
> >
> > --
> > http://twitter.com/tjake
> >
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>
--
http://twitter.com/tjake
Re: cassandra-3.1 branch and new merge order
Posted by Jonathan Ellis <jb...@gmail.com>.
I'm not a huge fan of leaving features to rot unmerged for a couple
months. What is wrong with "new features go to trunk, stable branches get
forked at release?"
On Mon, Nov 9, 2015 at 10:54 AM, Jake Luciani <ja...@gmail.com> wrote:
> Looking back at the tick-tock email chain we never really discussed this.
>
> Rather than having 3.1 and trunk I think we should have just trunk.
>
> I'd rather not let features sit in a branch with bugfixes going on top that
> can decay.
> They should be merged in when it's time to merge features for 3.even, post
> 3.odd.
>
> I know we have features in trunk today that aren't in 3.0 and we probably
> shouldn't have done that.
>
>
>
>
>
>
> On Mon, Nov 9, 2015 at 11:35 AM, Aleksey Yeschenko <al...@apache.org>
> wrote:
>
> > With 3.0.0 vote to be over soon, tick-tock is officially starting, and we
> > are creating a new branch for cassandra-3.1 release.
> >
> > New merge order: cassandra-2.2 -> cassandra-3.0 -> cassandra-3.1 -> trunk
> >
> > - cassandra-3.0 branch is going to continue representing the 3.0.x series
> > of releases (3.0 bugfixes only, as no new feature are supposed to go into
> > 3.0.x release series)
> > - cassandra-3.1 branch will contain 3.0 bugfixes *only*
> > - trunk represents the upcoming cassandra-3.2 release (fixes from 3.1 and
> > new features)
> >
> > --
> > AY
>
>
>
>
> --
> http://twitter.com/tjake
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced
Re: cassandra-3.1 branch and new merge order
Posted by Jake Luciani <ja...@gmail.com>.
Looking back at the tick-tock email chain we never really discussed this.
Rather than having 3.1 and trunk I think we should have just trunk.
I'd rather not let features sit in a branch with bugfixes going on top that
can decay.
They should be merged in when it's time to merge features for 3.even, post
3.odd.
I know we have features in trunk today that aren't in 3.0 and we probably
shouldn't have done that.
On Mon, Nov 9, 2015 at 11:35 AM, Aleksey Yeschenko <al...@apache.org>
wrote:
> With 3.0.0 vote to be over soon, tick-tock is officially starting, and we
> are creating a new branch for cassandra-3.1 release.
>
> New merge order: cassandra-2.2 -> cassandra-3.0 -> cassandra-3.1 -> trunk
>
> - cassandra-3.0 branch is going to continue representing the 3.0.x series
> of releases (3.0 bugfixes only, as no new feature are supposed to go into
> 3.0.x release series)
> - cassandra-3.1 branch will contain 3.0 bugfixes *only*
> - trunk represents the upcoming cassandra-3.2 release (fixes from 3.1 and
> new features)
>
> --
> AY
--
http://twitter.com/tjake