cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Kjellman <>
Subject Re: Versioning policy?
Date Sat, 16 Jan 2016 20:13:06 GMT
Correct, this is an open source project. 

If you want a Enterprise support story Datastax has an Enterprise option for you. 

> On Jan 16, 2016, at 11:19 AM, Anuj Wadehra <> wrote:
> Hi Jonathan
> It would be really nice if you could share your thoughts on the four points raised regarding
the Cassandra EOL process. I think similar things happen for other open source products and
it would be really nice if we could streamline such things for Apache Cassandra.
> ThanksAnuj
> Sent from Yahoo Mail on Android 
>  On Thu, 14 Jan, 2016 at 11:28 pm, Anuj Wadehra<> wrote:
  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" version date
rather than "GA" date of subsequent major releases.
> 2.  I think we should have "Formal EOL Announcement" on Apache Cassandra website.  
> 3. "Formal EOL Announcement" should come at least 6 months before the EOL, so that users
get reasonable time to      upgrade.
> 4. EOL Policy (even if flexible) should be stated on Apache Cassandra website
> EOL thread on users mailing list ended with the conclusion of raising a Wishlist JIRA
but I think above points are more about working on policy and processes rather than just a
wish list. 
> ThanksAnuj
> Sent from Yahoo Mail on Android 
>   On Thu, 14 Jan, 2016 at 10:57 pm, Jonathan Ellis<> wrote:  Hi
> 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 releases
> will be patched.
> Now, we also have three other release series currently being supported:
> 2.1.x: supported with critical fixes only until 4.0 is released, projected
> in November 2016 [2]
> 2.2.x: maintained until 4.0 is released
> 3.0.x: maintained for 6 months after 4.0, i.e. projected until May 2017
> I will add this information to the releases page [3].
> [1]
> [2] 4.0 will be an ordinary tick-tock release after 3.11, but we will be
> sunsetting deprecated features like Thrift so bumping the major version
> seems appropriate
> [3]
>> On Sun, Jan 10, 2016 at 9:29 PM, Maciek Sakrejda <> wrote:
>> There was a discussion recently about changing the Cassandra EOL policy on
>> the users list [1], but it didn't really go anywhere. I wanted to ask here
>> instead to clear up the status quo first. What's the current versioning
>> policy? The tick-tock versioning blog post [2] states in passing that two
>> major releases are maintained, but I have not found this as an official
>> policy stated anywhere. For comparison, the Postgres project lays this out
>> very clearly [3]. To be clear, I'm not looking for any official support,
>> I'm just asking for clarification regarding the maintenance policy: if a
>> critical bug or security vulnerability is found in version X.Y.Z, when can
>> I expect it to be fixed in a bugfix patch to that major version, and when
>> do I need to upgrade to the next major version.
>> [1]:
>> [2]:
>> [3]:
> -- 
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder,
> @spyced

View raw message