In CASSANDRA-17166 I am adding a test that detects breaking changes; this is not compile time, rather test case time…
We sadly don’t document when a config is free to remove, we should do that to enhance our warnings to users as well as make clear when free to remove; we spoke about this in 4.0 timeline that your deprecate in X.0.0 and remove in (X+1).0.0, we should document this in code for each config Sent from my iPhone > On Feb 12, 2022, at 10:54 AM, Dinesh Joshi <djo...@apache.org> wrote: > > +1 on introducing compile time checks to ensure backward compatibility. > > Confusion due to usage of deprecated settings is understandable. However, > settings marked deprecated should produce a warning in logs so that the > operators become aware of their usage in the YAML and can migrate to the > newer settings. > > Also breakages do happen once in a while. As long as we fix them quickly > and/or revert the code in the meanwhile it's fine. > >> On Feb 12, 2022, at 3:56 AM, Ekaterina Dimitrova <e.dimitr...@gmail.com> >> wrote: >> >> 15234 was a discussion about changing names and making parameters work with >> the old ones. Still working parameters, backward compatibility and not >> placeholders. >> >> Benedict, I can understand that when I said removal in this ticket you >> thought I will deprecate in Config but unfortunately it is not what I meant. >> I should have asked you also for review. I take the responsibility of doing >> a mistake here by removing in minor release thinking this is a bug that >> leads to dangerous confusion you can still use them. Indeed CHANGES.txt >> entry was created but not NEWS.txt and it requires a person to check which >> exact parameters were removed to take an action. I pushed a patch already to >> fix this. Docs are also on the way now when ADOC migration is over. >> >> One of the yaml parameters was actually also already removed with the >> rewrite of the messaging system in 4.0. I added back that one to Config too >> yesterday, to be on the safe side. >> >> “ I wonder if we should introduce a compile time check that validates config >> compatibility with prior versions, to avoid this in future” >> >> I think David is working on some tests to catch removed config in trunk, I >> will follow up on Monday with him. >> >> On Sat, 12 Feb 2022 at 5:49, bened...@apache.org <bened...@apache.org> wrote: >>> 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> >>> 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> 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> >>> 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> >>> 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 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. Thanks for the feedback. Cheers! >>> >>> >>> >
