On Fri, Jan 8, 2016 at 9:45 AM, Anuj Wadehra 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 giv
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
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 *any
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
wrote:
Why wouldn't you keep a bug free version of something in production? If
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 v
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 specifi
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
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
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 wrote:
> Thanks Robert !!!
>
> *"I don't run X.Y.Z versions where Z is under 6, so in gener
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 wo
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
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
"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.
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 dat
On Wed, Jan 6, 2016 at 5:26 PM, Anuj Wadehra 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
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
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
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:
17 matches
Mail list logo
