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 sam
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
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
serv
2015-11-10 0:35 GMT+08:00 Aleksey Yeschenko :
>
> - 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 di
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 somet
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 e
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 wrote:
> Looking back at the tick-tock email chain we never really discussed this.
>
>
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
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 bug
