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
