As discussed on 15234, there is never a rush to remove Config parameters, and 
it should only be done when there’s some clear value. Since the overhead of 
having an unused parameter is ~zero, in my opinion this occurs only when we 
really need the operator to consider the semantic impact of its deprecation.

We should never break minor upgrades, but we shouldn’t break any upgrade 
unnecessarily.

I wonder if we should introduce a compile time check that validates config 
compatibility with prior versions, to avoid this in future.

From: Dinesh Joshi <djo...@apache.org>
Date: Saturday, 12 February 2022 at 00:09
To: dev@cassandra.apache.org <dev@cassandra.apache.org>
Subject: Re: [RELEASE] Apache Cassandra 4.0.2 released
We should also have deprecation guidance in Config.java. This will help when 
anybody is making changes in the future.


On Feb 11, 2022, at 3:07 PM, Ekaterina Dimitrova 
<e.dimitr...@gmail.com<mailto:e.dimitr...@gmail.com>> wrote:

Note taken, I had to document only in 4.0.x that those are placeholder. I just 
opened ticket to fix that - CASSANDRA-17377. I am going to submit a patch soon

On Fri, 11 Feb 2022 at 17:44, Jeff Jirsa 
<jji...@gmail.com<mailto:jji...@gmail.com>> wrote:
We don't HAVE TO remove the Config.java entry - we can mark it as deprecated 
and ignored and remove it in a future version (and you could update Config.java 
to log a message about having a deprecated config option). It's a much better 
operator experience: log for a major version, then remove in the next.

On Fri, Feb 11, 2022 at 2:41 PM Ekaterina Dimitrova 
<e.dimitr...@gmail.com<mailto:e.dimitr...@gmail.com>> wrote:
This had to be removed in 4.0 but it wasn’t. The patch mentioned did it to fix 
a bug that gives impression those work. Confirmed with Benedict on the ticket.

I agree I absolutely had to document it better, a ticket for documentation was 
opened but it slipped from my mind with this emergency release this week. It is 
unfortunate it is still in our backlog after the ADOC migration.

Note taken. I truly apologize and I am going to prioritize CASSANDRA-17135. Let 
me know if there is anything else I can/should do at this point.

On Fri, 11 Feb 2022 at 17:26, Erick Ramirez 
<erick.rami...@datastax.com<mailto:erick.rami...@datastax.com>> wrote:
(moved dev@ to BCC)

It looks like the otc_coalescing_strategy config key is no longer supported in 
cassandra.yaml in 4.0.2, despite this not being mentioned anywhere in 
CHANGES.txt or NEWS.txt.

James, you're right -- it was removed by 
CASSANDRA-17132<https://issues.apache.org/jira/browse/CASSANDRA-17132> in 4.0.2 
and 4.1.

I agree that the CHANGES.txt entry should be clearer and we'll improve it plus 
add detailed info in NEWS.txt. I'll get this done soon in 
CASSANDRA-17135<https://issues.apache.org/jira/browse/CASSANDRA-17135>. Thanks 
for the feedback. Cheers!

Reply via email to