Thanks Jack !!
"Unfortunately how to get firm agreement  on what criteria should be used to 
judge "Production Ready" is unclear."
The most reliable way of determining production ready is to go to Apache 
Cassandra website. At any point of time, it clearly states the most 
stable/production ready version of Cassandra. 


"Clarity is also needed on the use of the term "major release"" By Major 
Release,  I mean 2.0,2.1,2.2,3.0..
I think Tick-Tock is only related to Apache Cassandra releases. I am not sure 
about the DataStax versions.

ThanksAnuj
 
    On Friday, 8 January 2016 9:14 PM, Jack Krupansky 
<jack.krupan...@gmail.com> wrote:
 

 "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 <mac...@heroku.com> 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]: http://www.planetcassandra.org/blog/cassandra-2-2-3-0-and-beyond/
[2]: http://www.postgresql.org/support/versioning/

Reply via email to