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
Thanks everyone!
On Mon, Nov 9, 2015 at 5:03 PM, Jake Luciani wrote:
> With 6 binding +1, 4 non-binding +1 and no -1 the vote passes. will
> publish shortly
>
>
> On Fri, Nov 6, 2015 at 4:34 PM, Jake Luciani wrote:
>
> > I propose the following artifacts for release as 3.0.0.
> >
> > sha1: 96f
The Cassandra team is pleased to announce the release of Apache Cassandra
version 3.0.0.
Top Cassandra 3.0 features:
* CQL optimized storage engine and sstable format
* Materialized views
* More efficient hints
Read more about features and upgrade instructions in NEWS.txt[2]
The Java driv
With 6 binding +1, 4 non-binding +1 and no -1 the vote passes. will
publish shortly
On Fri, Nov 6, 2015 at 4:34 PM, Jake Luciani wrote:
> I propose the following artifacts for release as 3.0.0.
>
> sha1: 96f407bce56b98cd824d18e32ee012dbb99a0286
> Git:
> http://git-wip-us.apache.org/repos/asf?p
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
non-binding +1
--
Michael
On 11/06/2015 03:34 PM, Jake Luciani wrote:
I propose the following artifacts for release as 3.0.0.
sha1: 96f407bce56b98cd824d18e32ee012dbb99a0286
Git:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.0-tentative
Artifacts:
https://rep
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
+1
On Fri, Nov 6, 2015 at 3:34 PM, Jake Luciani wrote:
> I propose the following artifacts for release as 3.0.0.
>
> sha1: 96f407bce56b98cd824d18e32ee012dbb99a0286
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.0-tentative
> Artifacts:
>
> https://re
11 matches
Mail list logo
