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_2...@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_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. > > Thanks > Anuj >
