You are viewing a plain text version of this content. The canonical link for it is here.

Posted to user@cassandra.apache.org by Anuj Wadehra <an...@yahoo.co.in> on 2016/01/05 15:34:07 UTC

Revisit Cassandra EOL Policy

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

Re: Revisit Cassandra EOL Policy

Posted by Anuj Wadehra <an...@yahoo.co.in>.

Thanks Mark!!"My sense is that most users manage their own C* clusters, not dozens of other ones for other clients/customers"In our case, product is released to several customers and thus, every Cassandra upgrade needs planning, packaging, multiple product testing cycles & release.

"One would hope it's via some sort of automation framework like Chef or something to help out with some of the heavy lifting."We don't use Chef.
ThanksAnuj

On Thursday, 7 January 2016 10:08 PM, Mark Greene <gr...@gmail.com> wrote:

Being on this mailing list for several years now, I would take a guess that most of the users here probably don't have a use case that aligns with yours. My sense is that most users manage their own C* clusters, not dozens of other ones for other clients/customers.

For my own use cases, I manage C* infrastructure for just one company and given the amount of bug fixes that have occurred in the 2.1.X versions, I'm glad it's moving fast and honestly not interested in staying on any old versions. I think a quick glance of the change logs would probably change your mind a bit. I think this really just the reality of a lot of the OSS out there. This stuff just moves so quickly that staying on old versions is pretty risky and catching up becomes a non-trivial task. We just chalk it up to the investment required for the technology selection. If we want to store vasts amount of data, not pay for the software, a reasonable person has to expect some kind of investment from their side.

To your point, supporting old versions is a pain. It really is. I can't imagine how many more bugs would arise by adopting some crazy convoluted EOL policy that forced C* developers to carry tech debt around for a long period of time.

We update C* about every 3 months or earlier depending on if we are impacted by a bug. It takes all but a few hours to do so it's not bad at all. Our move to 3.X will require far more effort but we don't anticipate making those sorts of big changes frequently so it's reasonable.

You didn't make any mention to how you manage all of your C* infrastructure. One would hope it's via some sort of automation framework like Chef or something to help out with some of the heavy lifting.

On Wed, Jan 6, 2016 at 8:26 PM, Anuj Wadehra <an...@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?

ThanksAnuj

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

Re: Revisit Cassandra EOL Policy

Posted by Mark Greene <gr...@gmail.com>.

Being on this mailing list for several years now, I would take a guess that
most of the users here probably don't have a use case that aligns with
yours. My sense is that most users manage their own C* clusters, not dozens
of other ones for other clients/customers.

For my own use cases, I manage C* infrastructure for just one company and
given the amount of bug fixes that have occurred in the 2.1.X versions, I'm
glad it's moving fast and honestly not interested in staying on any old
versions. I think a quick glance of the change logs would probably change
your mind a bit. I think this really just the reality of a lot of the OSS
out there. This stuff just moves so quickly that staying on old versions is
pretty risky and catching up becomes a non-trivial task. We just chalk it
up to the investment required for the technology selection. If we want to
store vasts amount of data, not pay for the software, a reasonable person
has to expect some kind of investment from their side.

To your point, supporting old versions is a pain. It really is. I can't
imagine how many more bugs would arise by adopting some crazy convoluted
EOL policy that forced C* developers to carry tech debt around for a long
period of time.

We update C* about every 3 months or earlier depending on if we are
impacted by a bug. It takes all but a few hours to do so it's not bad at
all. Our move to 3.X will require far more effort but we don't anticipate
making those sorts of big changes frequently so it's reasonable.

You didn't make any mention to how you manage all of your C*
infrastructure. One would hope it's via some sort of automation framework
like Chef or something to help out with some of the heavy lifting.

On Wed, Jan 6, 2016 at 8:26 PM, Anuj Wadehra <an...@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
> <an...@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
>
>

Re: Revisit Cassandra EOL Policy

Posted by Anuj Wadehra <an...@yahoo.co.in>.

Because the day some unforeseen critical bug pops up in future, you won't find any support from the community as the version is already EOL.

ThanksAnuj

On Friday, 8 January 2016 10:57 PM, Jonathan Haddad <jo...@jonhaddad.com> wrote:

Why wouldn't you keep a bug free version of something in production? If I found a version of *anything* that was bug free I don't think I'd ever upgrade again.
On Fri, Jan 8, 2016 at 9:18 AM Anuj Wadehra <an...@yahoo.co.in> wrote:

Thanks Robert !!!
"I don't run X.Y.Z versions where Z is under 6, so in general this does not result in me not-running-a-version-I-otherwise-would-have for longer than a few months each year."Agree !! But, if you upgrade to a version greater than X.Y.6, and then it goes EOL within months, you won't like to keep that version in Production even if it's bug free.

Thus, like some of the other Apache Open Source products, I think following points are worth considering:
1. EOL should be based on "most stable"/"production ready" version date rather than "GA" date of subsequent major releases.2. I think we should have "Formal EOL Announcement" on Apache Cassandra website.
3. "Formal EOL Announcement" should come at least 6 months before the EOL, so that users get reasonable time to upgrade.4. EOL Policy (even if flexible) should be stated on Apache Cassandra website
Please share your feedback.
ThanksAnuj

On Friday, 8 January 2016 12:07 AM, Robert Coli <rc...@eventbrite.com> wrote:

On Wed, Jan 6, 2016 at 5:26 PM, Anuj Wadehra <an...@yahoo.co.in> wrote:

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?

I upgrade Cassandra an average of once a year.
I don't run X.Y.Z versions where Z is under 6, so in general this does not result in me not-running-a-version-I-otherwise-would-have for longer than a few months each year.
There is really not that much penalty to being behind the curve, in fact there is often a significant penalty to being on the cutting edge.
=Rob

Re: Revisit Cassandra EOL Policy

Posted by Anuj Wadehra <an...@yahoo.co.in>.

Yes. I am planning to raise one JIRA for that. Thanks for the suggestion.
Anuj

    On Friday, 8 January 2016 11:06 PM, Michael Shuler <mi...@pbandjelly.org> wrote:

 On 01/08/2016 11:27 AM, Jonathan Haddad wrote:
> Why wouldn't you keep a bug free version of something in production?  If
> I found a version of *anything* that was bug free I don't think I'd ever
> upgrade again.

There are still 0.7 users.  :)

To OP, if you want to ask the project for some sort of official page to
refer to, open a wishlist JIRA. You could also start a version wiki page
on the topic and ask for feedback.

-- 
Michael

Re: Revisit Cassandra EOL Policy

Posted by Michael Shuler <mi...@pbandjelly.org>.

On 01/08/2016 11:27 AM, Jonathan Haddad wrote:
> Why wouldn't you keep a bug free version of something in production?  If
> I found a version of *anything* that was bug free I don't think I'd ever
> upgrade again.

There are still 0.7 users.  :)

To OP, if you want to ask the project for some sort of official page to
refer to, open a wishlist JIRA. You could also start a version wiki page
on the topic and ask for feedback.

-- 
Michael

Re: Revisit Cassandra EOL Policy

Posted by Jonathan Haddad <jo...@jonhaddad.com>.

Why wouldn't you keep a bug free version of something in production?  If I
found a version of *anything* that was bug free I don't think I'd ever
upgrade again.

On Fri, Jan 8, 2016 at 9:18 AM Anuj Wadehra <an...@yahoo.co.in> wrote:

> Thanks Robert !!!
>
> *"I don't run X.Y.Z versions where Z is under 6, so in general this does
> not result in me not-running-a-version-I-otherwise-would-have for longer
> than a few months each year."*
> Agree !! But, if you upgrade to a version greater than X.Y.6, and then it
> goes EOL within months, you won't like to keep that version in Production
> even if it's bug free.
>
> Thus, like some of the other Apache Open Source products, I think
> following points are worth considering:
>
> 1.  EOL should be based on "most stable"/"production ready" version date
> rather than "GA" date of subsequent major releases.
> 2.  I think we should have "Formal EOL Announcement" on Apache Cassandra
> website.
> 3. "Formal EOL Announcement" should come at least 6 months before the EOL,
> so that users get reasonable time to      upgrade.
> 4. EOL Policy (even if flexible) should be stated on Apache Cassandra
> website
>
> Please share your feedback.
>
> Thanks
> Anuj
>
>
> On Friday, 8 January 2016 12:07 AM, Robert Coli <rc...@eventbrite.com>
> wrote:
>
>
> On Wed, Jan 6, 2016 at 5:26 PM, Anuj Wadehra <an...@yahoo.co.in>
> wrote:
>
> 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?
>
>
> I upgrade Cassandra an average of once a year.
>
> I don't run X.Y.Z versions where Z is under 6, so in general this does not
> result in me not-running-a-version-I-otherwise-would-have for longer than a
> few months each year.
>
> There is really not that much penalty to being behind the curve, in fact
> there is often a significant penalty to being on the cutting edge.
>
> =Rob
>
>
>
>

Re: Revisit Cassandra EOL Policy

Posted by Anuj Wadehra <an...@yahoo.co.in>.

On Friday, 8 January 2016 12:07 AM, Robert Coli <rc...@eventbrite.com> wrote:

On Wed, Jan 6, 2016 at 5:26 PM, Anuj Wadehra <an...@yahoo.co.in> wrote:

Re: Revisit Cassandra EOL Policy

Posted by Anuj Wadehra <an...@yahoo.co.in>.

Thanks Maciek !!
"do you have a link to the versioning policy? The tick-tock versioning blog post [1] says that EOL happens after two major versions come out, but I can't find this stated more formally anywhere."I couldn't find any versioning policy related to EOL. I think it should be there on Apache website. The tick-tock blog post is the only reference.

"I don't have strong feelings about what the versioning policy should look like, but having clear expectations about what happens if there's a critical bug (i.e., can we expect a patch or do we need to upgrade major versions?) is very useful." No content available on supporting critical bugs in EOL versions. If EOL means no fixes, I think upgrade is the only option left.

ThanksAnuj

On Friday, 8 January 2016 3:16 AM, Maciek Sakrejda <ma...@heroku.com> wrote:

Anuj, do you have a link to the versioning policy? The tick-tock versioning blog post [1] says that EOL happens after two major versions come out, but I can't find this stated more formally anywhere. I'm interested in how long a given version will receive patches for security issues or critical data loss bugs (i.e., the policy of the Apache project itself, distinct from any support that may be available through Datastax). The Postgres project has a great write-up of their policy [2].

And for what it's worth, we are starting to use Cassandra and do have automation around it. I don't have strong feelings about what the versioning policy should look like, but having clear expectations about what happens if there's a critical bug (i.e., can we expect a patch or do we need to upgrade major versions?) is very useful.

[1]: http://www.planetcassandra.org/blog/cassandra-2-2-3-0-and-beyond/
[2]: http://www.postgresql.org/support/versioning/

Re: Revisit Cassandra EOL Policy

Posted by Robert Coli <rc...@eventbrite.com>.

On Fri, Jan 8, 2016 at 9:45 AM, Anuj Wadehra <an...@yahoo.co.in> wrote:

> *"Unfortunately how to get firm agreement  on what criteria should be used
> to judge "Production Ready" is unclear."*
>

Only you know how comfortable you are with the various types of risk that
are involved in a particular version choice given the requirements of your
business.

I agree that it is difficult to understand based on the project's approach
to bugfixes and what makes a change bugfix or not, especially late in the
lifetime of a given major version.

My rule of thumb and experience historically with Cassandra is that the
cost of being slightly behind the curve is lower than the cost of being at
the cutting edge. A number of my clusters are 1.2.x and run fine, I am in
no particular rush to upgrade them. When I do, I will do so very quickly
from 1.2 to 2.0 to 2.1. New clusters I deploy on 2.1, and would likely do
2.2 soon.

=Rob

Re: Revisit Cassandra EOL Policy

Posted by Anuj Wadehra <an...@yahoo.co.in>.

Thanks Jack !!
"Unfortunately how to get firm agreement on what criteria should be used to judge "Production Ready" is unclear."
The most reliable way of determining production ready is to go to Apache Cassandra website. At any point of time, it clearly states the most stable/production ready version of Cassandra.

"Clarity is also needed on the use of the term "major release"" By Major Release, I mean 2.0,2.1,2.2,3.0..
I think Tick-Tock is only related to Apache Cassandra releases. I am not sure about the DataStax versions.

ThanksAnuj

On Friday, 8 January 2016 9:14 PM, Jack Krupansky <ja...@gmail.com> wrote:

"declared Production Ready"
I agree that mere GA of x.y.0 should not start the clock for EOL of x.y. Some people take the position that x.y is not production ready until x.y.5 is out. Unfortunately how to get firm agreement on what criteria should be used to judge "Production Ready" is unclear.
Clarity is also needed on the use of the term "major release". Some people use that for strictly x.0 while others use it for x.y.
In the new tick-tock scheme, it is unknown how many tocks it will take before "Production Ready" stability is reached for 3.x, for example.
One measure of stability is when DataStax Enterprise incorporates a new Cassandra release. But even then, it may take a x.y.3 or 4 or 5 to hit a conservative level of production stability.
In fact, if you synchronized your selection of Cassandra to match DSE x.y.5, you might be about as close to a criteria for Production Ready as you could ever realistically expect to get. That doesn't help you with the EOL question though.

-- Jack Krupansky
On Thu, Jan 7, 2016 at 4:45 PM, Maciek Sakrejda <ma...@heroku.com> wrote:

[1]: http://www.planetcassandra.org/blog/cassandra-2-2-3-0-and-beyond/
[2]: http://www.postgresql.org/support/versioning/

Re: Revisit Cassandra EOL Policy

Posted by Jack Krupansky <ja...@gmail.com>.

"declared Production Ready"

I agree that mere GA of x.y.0 should not start the clock for EOL of x.y.
Some people take the position that x.y is not production ready until x.y.5
is out. Unfortunately how to get firm agreement  on what criteria should be
used to judge "Production Ready" is unclear.

Clarity is also needed on the use of the term "major release". Some people
use that for strictly x.0 while others use it for x.y.

In the new tick-tock scheme, it is unknown how many tocks it will take
before "Production Ready" stability is reached for 3.x, for example.

One measure of stability is when DataStax Enterprise incorporates a new
Cassandra release. But even then, it may take a x.y.3 or 4 or 5 to hit a
conservative level of production stability.

In fact, if you synchronized your selection of Cassandra to match DSE
x.y.5, you might be about as close to a criteria for Production Ready as
you could ever realistically expect to get. That doesn't help you with the
EOL question though.

-- Jack Krupansky

On Thu, Jan 7, 2016 at 4:45 PM, Maciek Sakrejda <ma...@heroku.com> wrote:

> Anuj, do you have a link to the versioning policy? The tick-tock
> versioning blog post [1] says that EOL happens after two major versions
> come out, but I can't find this stated more formally anywhere. I'm
> interested in how long a given version will receive patches for security
> issues or critical data loss bugs (i.e., the policy of the Apache project
> itself, distinct from any support that may be available through Datastax).
> The Postgres project has a great write-up of their policy [2].
>
> And for what it's worth, we are starting to use Cassandra and do have
> automation around it. I don't have strong feelings about what the
> versioning policy should look like, but having clear expectations about
> what happens if there's a critical bug (i.e., can we expect a patch or do
> we need to upgrade major versions?) is very useful.
>
> [1]: http://www.planetcassandra.org/blog/cassandra-2-2-3-0-and-beyond/
> [2]: http://www.postgresql.org/support/versioning/
> 
>

Re: Revisit Cassandra EOL Policy

Posted by Maciek Sakrejda <ma...@heroku.com>.

Anuj, do you have a link to the versioning policy? The tick-tock versioning
blog post [1] says that EOL happens after two major versions come out, but
I can't find this stated more formally anywhere. I'm interested in how long
a given version will receive patches for security issues or critical data
loss bugs (i.e., the policy of the Apache project itself, distinct from any
support that may be available through Datastax). The Postgres project has a
great write-up of their policy [2].

And for what it's worth, we are starting to use Cassandra and do have
automation around it. I don't have strong feelings about what the
versioning policy should look like, but having clear expectations about
what happens if there's a critical bug (i.e., can we expect a patch or do
we need to upgrade major versions?) is very useful.

[1]: http://www.planetcassandra.org/blog/cassandra-2-2-3-0-and-beyond/
[2]: http://www.postgresql.org/support/versioning/

Re: Revisit Cassandra EOL Policy

Posted by Robert Coli <rc...@eventbrite.com>.

On Wed, Jan 6, 2016 at 5:26 PM, Anuj Wadehra <an...@yahoo.co.in> wrote:

> 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?
>

I upgrade Cassandra an average of once a year.

I don't run X.Y.Z versions where Z is under 6, so in general this does not
result in me not-running-a-version-I-otherwise-would-have for longer than a
few months each year.

There is really not that much penalty to being behind the curve, in fact
there is often a significant penalty to being on the cutting edge.

=Rob

Re: Revisit Cassandra EOL Policy

Posted by Jeff Jirsa <je...@crowdstrike.com>.

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 <Ja...@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 <an...@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
<an...@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

Re: Revisit Cassandra EOL Policy

Posted by Anuj Wadehra <an...@yahoo.co.in>.

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.144. 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.

ThanksAnuj

On Thursday, 7 January 2016 10:51 PM, Janne Jalkanen <Ja...@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 <an...@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?

ThanksAnuj

Re: Revisit Cassandra EOL Policy

Posted by Janne Jalkanen <Ja...@ecyrd.com>.

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 <an...@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
> <an...@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
>

Re: Revisit Cassandra EOL Policy

Posted by Anuj Wadehra <an...@yahoo.co.in>.

ThanksAnuj