cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <Janne.Jalka...@ecyrd.com>
Subject Re: Revisit Cassandra EOL Policy
Date Thu, 07 Jan 2016 17:20:45 GMT

If you wish to have a specific EOL policy, you need to basically buy it. It's unusual for
open source projects to give any sort of an EOL policy; that's something that people with
very specific requirements are willing to cough up a lot of money on. And getting money by
giving support on older versions, having contracts and EOL dates and all that stuff that corporations
love is something that enables companies to actually make money on open source projects.

Have you considered contacting Datastax and checked their Cassandra EOL policy?  They seem
to be very well aligned on what you are looking for.

http://www.datastax.com/support-policy#9 <http://www.datastax.com/support-policy#9>

/Janne

> On 07 Jan 2016, at 03:26, Anuj Wadehra <anujw_2003@yahoo.co.in> wrote:
> 
> I would appreciate if you guys share your thoughts on the concerns I expressed regarding
Cassandra End of Life policy. I think these concerns are quite genuine and should be openly
discussed so that EOL is more predictable and generates less overhead for the users.
> 
> I would like to understand how various users are dealing with the situation. Are you
upgrading Cassandra every 3-6 mths? How do you cut short your planning,test and release cycles
for Cassandra upgrades in your application/products?
> 
> 
> 
> 
> Thanks
> Anuj
> 
> 
> 
> On Tue, 5 Jan, 2016 at 8:04 pm, Anuj Wadehra
> <anujw_2003@yahoo.co.in> wrote:
> Hi,
> 
> As per my understanding, a Cassandra version n is implicitly declared EOL when two major
versions are released after the version n i.e. when version n + 2 is released.
> 
> I think the EOL policy must be revisted in interest of the expanding Cassandra user base.

> 
> Concerns with current EOL Policy:
> 
> In March 2015, Apache web site mentioned that 2.0.14 is the most stable version of the
Cassandra recommended for Production. So, one would push its clients to upgrade to 2.0.14
in Mar 2015. It takes months to roll out a Cassandra upgrade to all your clients and by the
time all your clients get the upgrade, the version is declared EOL with the release of 2.2
in Aug 2015 (within 6 mths of being declared production ready). I completely understand that
supporting multiple versions is tougher but at the same time it is very painful and somewhat
unrealistic for users to push Cassandra upgrades to all thier clients after every few months.
> 
> One proposed solution could be to declare a version n as EOL one year after n+1 was declared
Production Ready. E.g. if 2.1.7 is the first production ready release of 2.1 which is released
in Jun 2015, I would declare 2.0 EOL in Jun 2016. This gives reasonable time for users to
plan upgrades.
> 
> Moreover, I think the EOL policy and declarations must be documented explicitly on Apache
web site.
> 
> Please share your feedback on revisting the EOL policy.
> 
> Thanks
> Anuj
> 


Mime
View raw message