You chose a specific point in time that is especially painful. Had you chosen most of 2014, you would have had a long period of 2.0.x that was stable.
Yes, if you were deploying in April 2015, you had an unpleasant choice between
an about-to-EOL 2.0 and a omg-memory-leak 2.1 – if you deploy right now, you
have the same basic problem (2.1 about to EOL, 2.2 isn’t stable, 3.0 is a
question mark).
Most of us choose the stable one until/unless we need something from the
“almost stable” one, and expect that we’ll need to upgrade.
Having played this game since 2010, the answer is: “get good at automating
upgrades”
From: Anuj Wadehra
Reply-To: "user@cassandra.apache.org", Anuj Wadehra
Date: Friday, January 8, 2016 at 9:03 AM
To: "user@cassandra.apache.org"
Subject: Re: Revisit Cassandra EOL Policy
Thanks Janne !!
"If you wish to have a specific EOL policy, you need to basically buy it."
We are not interested in a buying custom EOL policy. I am trying to understand
how people deal with quick EOLs in this fast paced environment. If my concerns
seem genuine, should we revisit the EOL Policy ?
My Main Concern:
A Cassandra version which is declared "most stable" on Apache web site today,
should not be declared EOL within 4 months.
I will try to explain you with some facts and events which happened in 2015.
1. Apr 2015 - A user considers upgrading his Production Cassandra to latest
stable version.
2. Apr 2015- Apache website shows that 2.0.14 is the "most stable" release
which is production ready.
2.1.x is out but not ready for production.
3. Apr 2015-User decides to upgrade to 2.0.14
4. June 2015- User completes packing and testing of his application/product
with new 2.0.14. New Application/product with 2.0.14 is ready to be released.
5.Aug 2015- Cassandra 2.2.x is out and 2.0.x is implicitly declared EOL.
6. Aug 2015- :( Time to plan another upgrade after 2 months of releasing the
product/application with upgraded Cassandra
I hope the above example with all the facts explains my situation.
Thanks
Anuj
On Thursday, 7 January 2016 10:51 PM, Janne Jalkanen <janne.jalka...@ecyrd.com>
wrote:
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
/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
smime.p7s
Description: S/MIME cryptographic signature
