Mirror of Apache Cassandra
Java Python GAP Shell Thrift PowerShell Other
Pull request Compare This branch is 30 commits ahead, 1812 commits behind apache:trunk.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
bin
conf
debian
doc
examples
ide
interface
lib
pylib
src
test
tools
.gitignore
.rat-excludes
CHANGES.txt
CONTRIBUTING.md
INSTACLUSTR-README.md
LICENSE.txt
NEWS.txt
NOTICE.txt
README.asc
build.properties.default
build.xml
eclipse_compiler.properties

README.asc

Cassandra 3.7 LTS

This is repository contains Apache Cassandra 3.7 with a number of bugfixes from later versions of Apache Cassandra we have backported to 3.7. If you want to know more and how to build and install see the official Apache Cassandra README

FAQ

Is this a fork?

No, This is just Cassandra with a different release cadence for those who want 3.x features but are slightly more risk averse than the current schedule allows.

Why not just use the official release?

With the 3.x tick-tock branch we have encountered more instability than with the previous release cadence. We feel that releasing new features every other release makes it very hard for operators to stabilize their production environment without bringing in brand new features that are not battle tested. With the dual release of Cassandra 3.8 and 3.9 simultaneously the bug fix branch included new and real-world untested features, specifically CDC. We have decided to stick with Cassandra 3.7 and instead backport critical issues and maintain it ourselves rather than trying to stick with the current Apache Cassandra release cadence.

Why backport?

At Instaclustr we support and run a number of different versions of Apache Cassandra on behalf of our customers. Over the course of managing Cassandra for our customers we often encounter bugs. There are existing patches for some of them, others we patch ourselves. Generally, if we can, we try to wait for the next official Apache Cassandra release, however in the need to ensure our customers remain stable and running we will sometimes backport bugs and write our own hotfixes (which are also submitted back to the community).

Why release it?

A number of our customers and people in the community have asked if we would make this available, which we are more than happy to do so. This repository represents what we at Instaclustr run in production for Cassandra 3.7 and this is our way of helping the community get a similar level of stability as what you would get from our managed service.

How long will you support this?

We will be aiming to maintain our 3.7 release for the next 6 months or so. The lifetime will primarily be driven by the needs of our paying customers. There has been some initial discussions on the Cassandra mailing list about abandoning the current release cadence, should this happen it is likely we will start to follow the official Apache Cassandra releases more closely, however we will probably still maintain this repository with just a much shorter list of backported bugfixes. As we backport patches to the base 3.7 release, we will update the list below.

Where are the debs at?

We will just be maintaining a repository and not distributing or maintaining build artefacts and is this is provided as is without warranty.

Will you help me?

We will keep an eye on the issues page of this github repository and try to help there, however if you want commercial support for our release contact us for details.

Current patches backported

We are also working to backport additional patches that we see as required, however this is an ongoing process and there will always be fixes that "need" to be backported that we haven’t done yet. We will tag commits with a minor version number for releases that we are ourselves running in production clusters. E.g. 3.7.1. Build artefacts will not be release builds and as such you will see this in the version numbers reported in various places by Cassandra.

How are you labeling these versions?

Currently we are putting using a minor version appended to the major version (e.g. for 3.7 this release is 3.7.1). If in the future this conflicts with official versioning we will change our versioning to remove any confusion.

Is this tested?

Yes it sure is! We rerun all associated unit tests, dtests and our own internal tests. Tests for each backported patch are also run. We also run this version ourselves internally for our own monitoring and metrics system. Having said that, there will always still be bugs and there will also be bugs with patches we have yet to backport. If you want super duper stability, then look at the 2.x branches.

I want to contribute!

Awesome! We will be maintaining this repository under the following general rules (though we may make well explained exceptions):

  • All code and backported fixes in this repository can be found in some form in various branches in the ASF project repository.

  • We will not accept pull requests for patches that do not have a corresponding Jira ticket in the ASF Cassandra jira repository.

  • The only exception to this will be if there is a bug with the backport itself.

  • We will only backport bugfixes, not features.

  • Bugfixes will generally be for major issues (or issues that annoy us).

  • We prioritise fixing issues our customers are experiencing, then fixing issues in the official Cassandra project and only then backporting issues listed here.

  • If you think you’ve found a bug in Cassandra, reproduce in an official release then raise a Jira.

  • If you think you’ve found a bug specific to our implementation, raise an issue in this github.

This is terrible why don’t you include XYZ?

Feel free to raise an issue and suggest something that is missing, we will be very friendly! There are definitely some things that need to be included here e.g. Time Window Compaction Strategy (TWCS), which we may include soon.