Add deprecated to info file

I am wondering if we should have a dedicated page, maybe documentation? maybe change record?? I don't know what would be best.
Because i think it would be good to give more background information as to why this module is scheduled to go away and what to do about it.

I've started a draft change record, please feel free to edit it. https://www.drupal.org/node/3487924 →

Thanks! Yes a change record is a great start.
Though one of the things Config Filter is still used for in Config Split and Config Ignore is for testing. I created a trait that abstracts the difference between the config filter and core API so that one can write a Test for the module when it is using filter plugins and and then rewrite the module to use the transformation events and the same test will still pass. It was instrumental for the refactoring of the two mentioned modules.

Maybe we add the trait to core too and if it doesn't get in Drupal 11, maybe we create Config Filter 3.0.x with just the trait and none of the actual code. Does that sound like a plan?

Do we need a new Drupal core issue to propose creating a new test trait for the config import export transformation api? If so where would we propose adding it? Maybe here? https://git.drupalcode.org/project/drupal/-/tree/11.x/core/modules/confi...

Are we talking about this file? https://git.drupalcode.org/project/config_filter/-/blob/8.x-1.x/tests/sr...

I don't know if we need an issue in core, I don't remember if I created one years ago. But maybe I didn't and yes we need one? But on the other hand do we?

And yes that is the trait, though for core we would probably rather use the one from 2.x ie https://git.drupalcode.org/project/config_filter/-/blob/8.x-2.x/tests/sr... (if you compare the two versions of the trait you can see where config filter 1.x does in the trait what config filter does in the event subscriber bridging the API)

But also if Config Filter is not involved any more then maybe it could also make sense for the modules that needed it to adopt that code. The original point was to make the transition from Config Filter to the storage transformation API easier. So getting rid of the dev dependency on config filter requires some amount of code, either by changing the namespace of the trait if it goes "as is" into core, or copying the trait to the module and renaming the namespace. Maybe the difference between the SyncFileStorage and the sync storage service is negligible when config filter is not swapping it out, and the active storage doesn't need to be a readonly storage if you know what you are doing?

You can tell I haven't made up my mind :D
Thanks for helping me figure this out!