[VOTE] Release Apache Cassandra 3.10 (Take 4)

I propose the following artifacts for release as 3.10. sha1: 9c2ab25556fad06a6a4d58f4bb652719a8a1bc27 Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.10-tentative Artifacts:

Re: Wrapping up tick-tock

Mick proposed it (semver) in one of the release proposals, and I dropped the ball on sending out the actual "vote on which release plan we want to use" email, because I messed up and got busy. On Fri, Jan 13, 2017 at 11:26 AM, Russell Bradberry wrote: > Has any thought

Re: Wrapping up tick-tock

Has any thought been given to SemVer? http://semver.org/ -Russ On 1/13/17, 1:57 PM, "Jason Brown" wrote: It's fine to limit the minimum time between major releases to six months, but I do not think we should force a major just because n months have passed. I

Re: [VOTE] 3.X branch feature freeze

+1 On Fri, Jan 13, 2017 at 10:52 AM, Josh McKenzie wrote: > +1 > > On Fri, Jan 13, 2017 at 1:43 PM, Blake Eggleston > wrote: > > > +1 > > > > > > On January 13, 2017 at 12:38:55 PM, Michael Shuler ( > mich...@pbandjelly.org) > > wrote: > > > > +1 to

Re: Wrapping up tick-tock

Based on the rate of change in Tick Tock, I really doubt it'll be a problem. On Fri, Jan 13, 2017 at 11:07 AM sankalp kohli wrote: > + to Jason idea. We should have a minimum of 6 months between a major > version. > > On Fri, Jan 13, 2017 at 10:57 AM, Jason Brown

Re: Wrapping up tick-tock

+ to Jason idea. We should have a minimum of 6 months between a major version. On Fri, Jan 13, 2017 at 10:57 AM, Jason Brown wrote: > It's fine to limit the minimum time between major releases to six months, > but I do not think we should force a major just because n

Re: Wrapping up tick-tock

It's fine to limit the minimum time between major releases to six months, but I do not think we should force a major just because n months have passed. I think we should up the major only when we have significant (possibly breaking) changes/features. It would seem odd to have a 6.0 that's

Re: [VOTE] 3.X branch feature freeze

+1 On Fri, Jan 13, 2017 at 1:43 PM, Blake Eggleston wrote: > +1 > > > On January 13, 2017 at 12:38:55 PM, Michael Shuler (mich...@pbandjelly.org) > wrote: > > +1 to freeze with this clarified branch situation. > > -- > Michael > > On 01/13/2017 11:53 AM, Aleksey Yeschenko

Re: [VOTE] 3.X branch feature freeze

+1 On January 13, 2017 at 12:38:55 PM, Michael Shuler (mich...@pbandjelly.org) wrote: +1 to freeze with this clarified branch situation. -- Michael On 01/13/2017 11:53 AM, Aleksey Yeschenko wrote: > To elaborate further, under the current consensus there would be no 3.12 > release.

Re: [VOTE] 3.X branch feature freeze

+1 to freeze with this clarified branch situation. -- Michael On 01/13/2017 11:53 AM, Aleksey Yeschenko wrote: > To elaborate further, under the current consensus there would be no 3.12 > release. > > Meaning that there are a few features that already made it to 3.X (3.12) that > would >

Re: [VOTE] 3.X branch feature freeze

Progress: Yes and no. I made a patch that made our cluster stable performance wise but introduces a consistency issue I am aware of. We can deal with it and I prefer this over severe performance problems. But this is nothing you can offer to regular users. I created a bunch of tickets related to

Re: [VOTE] 3.X branch feature freeze

+1 On Fri, Jan 13, 2017 at 11:21 AM, Aleksey Yeschenko wrote: > Hi all! > > It seems like we have a general consensus on ending tick-tock at 3.11, and > moving > on to stabilisation-only for 3.11.x series. > > In light of this, I suggest immediate feature freeze in the 3.X

Re: [VOTE] 3.X branch feature freeze

In my opinion, stabilising MVs would count towards bug fixing, to totally acceptable for the 3.11.X line. No conflict here. --  AY On 13 January 2017 at 17:56:06, Jonathan Haddad (j...@jonhaddad.com) wrote: +1 (non binding) to feature freeze. I also like the idea of stabilizing MVs. Ben,

Re: [VOTE] 3.X branch feature freeze

+1 (non binding) to feature freeze. I also like the idea of stabilizing MVs. Ben, you've probably been the most vocal about the issues, have you made any progress towards making them work any better during bootstrap / etc? Any idea of fixing them is a major undertaking? Jon On Fri, Jan 13,

Re: [VOTE] 3.X branch feature freeze

To elaborate further, under the current consensus there would be no 3.12 release. Meaning that there are a few features that already made it to 3.X (3.12) that would either: a) have to be reverted b) have to be discarded together with the remained of the 3.X branch If the vote goes through, I

Re: [VOTE] 3.X branch feature freeze

+1 also I appreciate any effort on MV stability. It is an official 3.x feature but not production ready for the masses. Am 13.01.2017 18:34 schrieb "Jonathan Ellis" : > +1 > > On Fri, Jan 13, 2017 at 11:21 AM, Aleksey Yeschenko > wrote: > > > Hi all! > > >

Re: [VOTE] 3.X branch feature freeze

+1 On Fri, Jan 13, 2017 at 11:21 AM, Aleksey Yeschenko wrote: > Hi all! > > It seems like we have a general consensus on ending tick-tock at 3.11, and > moving > on to stabilisation-only for 3.11.x series. > > In light of this, I suggest immediate feature freeze in the 3.X

[VOTE] 3.X branch feature freeze

Hi all! It seems like we have a general consensus on ending tick-tock at 3.11, and moving on to stabilisation-only for 3.11.x series. In light of this, I suggest immediate feature freeze in the 3.X branch. Meaning that only bug fixes go to the 3.11/3.X branch from now on. All new features