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?
ThanksAnuj On Tue, 5 Jan, 2016 at 8:04 pm, Anuj Wadehra<anujw_2...@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. ThanksAnuj
