Re: [VOTE] Release Apache Cassandra 3.0.0
+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://repository.apache.org/content/repositories/orgapachecassandra-1089/org/apache/cassandra/apache-cassandra/3.0.0/ > Staging repository: > https://repository.apache.org/content/repositories/orgapachecassandra-1089/ > > The artifacts as well as the debian package are also available here: > http://people.apache.org/~jake > > The vote will be open for 72 hours (longer if needed). > > [1]: http://goo.gl/0vghCL (CHANGES.txt) > [2]: http://goo.gl/xAElQy (NEWS.txt) >
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
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 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
Re: cassandra-3.1 branch and new merge order
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. > > 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 > 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
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 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 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 > > 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: [VOTE] Release Apache Cassandra 3.0.0
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://repository.apache.org/content/repositories/orgapachecassandra-1089/org/apache/cassandra/apache-cassandra/3.0.0/ Staging repository: https://repository.apache.org/content/repositories/orgapachecassandra-1089/ The artifacts as well as the debian package are also available here: http://people.apache.org/~jake The vote will be open for 72 hours (longer if needed). [1]: http://goo.gl/0vghCL (CHANGES.txt) [2]: http://goo.gl/xAElQy (NEWS.txt)
Re: cassandra-3.1 branch and new merge order
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 > 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 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 > > > 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
[VOTE RESULT] Release Apache Cassandra 3.0.0
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=cassandra.git;a=shortlog;h=refs/tags/3.0.0-tentative > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-1089/org/apache/cassandra/apache-cassandra/3.0.0/ > Staging repository: > https://repository.apache.org/content/repositories/orgapachecassandra-1089/ > > The artifacts as well as the debian package are also available here: > http://people.apache.org/~jake > > The vote will be open for 72 hours (longer if needed). > > [1]: http://goo.gl/0vghCL (CHANGES.txt) > [2]: http://goo.gl/xAElQy (NEWS.txt) > >
[RELEASE] Apache Cassandra 3.0.0 released
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 driver beta for 3.0.0 will be officially released within the next week. In the meantime, use the version included in the release under /lib. The Python driver rc has been released as '3.0.0rc1' Apache Cassandra is a fully distributed database. It is the right choice when you need scalability and high availability without compromising performance. http://cassandra.apache.org/ Downloads of source and binary distributions are listed in our download section: http://cassandra.apache.org/download/ This version is a first release[1] on the 3.0 series. As always, please pay attention to the release notes[2] and Let us know[3] if you were to encounter any problem. Enjoy! [1]: http://goo.gl/TduZdw (CHANGES.txt) [2]: http://goo.gl/mJxdHZ (NEWS.txt) [3]: https://issues.apache.org/jira/browse/CASSANDRA
Re: [VOTE RESULT] Release Apache Cassandra 3.0.0
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: 96f407bce56b98cd824d18e32ee012dbb99a0286 > > Git: > > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.0-tentative > > Artifacts: > > > https://repository.apache.org/content/repositories/orgapachecassandra-1089/org/apache/cassandra/apache-cassandra/3.0.0/ > > Staging repository: > > > https://repository.apache.org/content/repositories/orgapachecassandra-1089/ > > > > The artifacts as well as the debian package are also available here: > > http://people.apache.org/~jake > > > > The vote will be open for 72 hours (longer if needed). > > > > [1]: http://goo.gl/0vghCL (CHANGES.txt) > > [2]: http://goo.gl/xAElQy (NEWS.txt) > > > > > -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced
Re: cassandra-3.1 branch and new merge order
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 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
