Agree Sent from my iPhone
> On Feb 13, 2022, at 5:53 AM, Ekaterina Dimitrova <e.dimitr...@gmail.com> > wrote: > > > “ 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” > > This and IMHO it should be absolutely clear where deprecated means that > things are still usable (but will be removed) and where it means that they > are removed(maybe replaced by different solution) and this is just a > placeholder. > >> On Sun, 13 Feb 2022 at 8:34, David Capwell <dcapw...@apple.com> wrote: >> 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! >>>>> >>>>> >>>>> >>>
