cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jack Krupansky <>
Subject Re: Revisit Cassandra EOL Policy
Date Fri, 08 Jan 2016 15:44:31 GMT
"declared Production Ready"

I agree that mere GA of x.y.0 should not start the clock for EOL of x.y.
Some people take the position that x.y is not production ready until x.y.5
is out. Unfortunately how to get firm agreement  on what criteria should be
used to judge "Production Ready" is unclear.

Clarity is also needed on the use of the term "major release". Some people
use that for strictly x.0 while others use it for x.y.

In the new tick-tock scheme, it is unknown how many tocks it will take
before "Production Ready" stability is reached for 3.x, for example.

One measure of stability is when DataStax Enterprise incorporates a new
Cassandra release. But even then, it may take a x.y.3 or 4 or 5 to hit a
conservative level of production stability.

In fact, if you synchronized your selection of Cassandra to match DSE
x.y.5, you might be about as close to a criteria for Production Ready as
you could ever realistically expect to get. That doesn't help you with the
EOL question though.

-- Jack Krupansky

On Thu, Jan 7, 2016 at 4:45 PM, Maciek Sakrejda <> wrote:

> Anuj, do you have a link to the versioning policy? The tick-tock
> versioning blog post [1] says that EOL happens after two major versions
> come out, but I can't find this stated more formally anywhere. I'm
> interested in how long a given version will receive patches for security
> issues or critical data loss bugs (i.e., the policy of the Apache project
> itself, distinct from any support that may be available through Datastax).
> The Postgres project has a great write-up of their policy [2].
> And for what it's worth, we are starting to use Cassandra and do have
> automation around it. I don't have strong feelings about what the
> versioning policy should look like, but having clear expectations about
> what happens if there's a critical bug (i.e., can we expect a patch or do
> we need to upgrade major versions?) is very useful.
> [1]:
> [2]:
> ‚Äč

View raw message