[VOTE] Release Apache Cassandra 3.2.1

I propose the following artifacts for release as 3.2.1. sha1: 2ac95bd6c5699a605e6f4256cb17b016c99e6dda Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.2.1-tentative Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1097/org/apache

Concurrent connections

Greetings, I was looking for a way to limit amount of concurrent connection on per user base, but it looks like Cassandra doesn't support it. So for the lack of it, I switched to the per IP base, which Cassandra supports. Now here is the question comes: What are the values for native_transport_m

Re: Versioning policy?

Thanks, Jonathan. The end-of-life (EOL) question is still dangling out there - when does 3.x go off support, after 3.x+3 or six months after 4.0? Or... six months after 5.0? -- Jack Krupansky On Thu, Jan 14, 2016 at 6:15 PM, Jonathan Ellis wrote: > On Thu, Jan 14, 2016 at 4:26 PM, Jack Krupans

Re: Versioning policy?

On Thu, Jan 14, 2016 at 4:26 PM, Jack Krupansky wrote: > Jonathan, just to complete the list, it would be help to state: > > 3.1.x will be maintained until > 3.2 will be maintained until > One of the confusing things about tick tock is that we're stuck with numbers that look like the old ones

Encryption

Greetings, I'm looking at the data-at-transit encryption implementation from the security point of view, and I'm mildly surprised with following: 1) Passwords for keystore and truststore are in clear text in cassandra.yaml (Why? If we are going into the trouble of creating keystore and truststore

Re: Versioning policy?

Jonathan, just to complete the list, it would be help to state: 3.1.x will be maintained until 3.2 will be maintained until And in general, 3.x (x != 0) will be maintained until (and does x even vs. odd affect the rule) And what exactly is the general rule/criteria for when 3.x will be conside

Re: Versioning policy?

Hi Jonathan, Thanks for the crisp communication regarding the tick tock release & EOL. I think its worth considering some points regarding EOL policy and it would be great if you can share your thoughts on below points: 1.  EOL of a release should be based on "most stable"/"production ready" vers

Re: Versioning policy?

Hi Maciek, First let's talk about the tick-tock series, currently 3.x. This is pretty simple: outside of the regular monthly releases, we will release fixes for critical bugs against the most recent bugfix release, the way we did recently with 3.1.1 for CASSANDRA-10822 [1]. No older tick-tock re

Re: Versioning policy?

Mark, what would the policy dictate if the bug is in a feature that was introduced in 3.x and the feature wasn't in 3.0 and the current release is 3.x+k where k is greater than two - technically 3.x is no longer supported, so does that mean no backporting of the fix and only 3.x+k+1 would get the b

Re: Versioning policy?

Let's do a couple examples: 1. Current release: 3.4.0, bug found in 3.1.0 that also exists in subsequent versions; the bug fix will be ported back to 3.0.x and 3.5.0. 2. Current release 3.3.0, bug found in 3.3.0; the bug fix will be ported back to 3.0.x and 3.4.0. In rare cases, a 3.3.