would it be possible to include these events in the TypedConfig deprecated logic?

I can imagine we may want to add something like "DeprecatedEvent" parameter to model this behaviour, because iirc the "Deprecated" parameter present there will error the scaler parsing. Or maybe we change the current behaviour to not fail and throw event instead?

Thank you for the good feedback. In retrospect, it is indeed much better to handle this through TypedConfig. I’ve restructured it accordingly. I created a new parameter called deprecatedAnnounce. This will issue both, an info message (to maintain the 'old' behavior), and an event. This means I’ve removed the info message directly from the scaler, and it now also runs through TypedConfig, so the message only needs to be specified once.

I believe the other 'deprecated' parameter should remain in place. It makes the flow more logical. First, there will be an announcement, typically for two releases. After that, it can be converted to deprecated status, triggering an error. This is important because it provides the reason for the scaler's failure if the parameter is still in use.

Perhaps it would be good to set a standard, once something is truly deprecated and causes an error, we keep showing it for two releases and then remove the parameter to keep the code clean. So in summary:

show 2 releases: deprecatedAnnounce: parameter x is deprecated and will be removed in release x then remove the deprecatedAnnounce, then; show 2 releases: deprecated: parameter x is deprecated, use parameter x instead then remove deprecated tag

What are your thoughts?

I like this :)

We should document this here: https://github.com/kedacore/governance/blob/main/DEPRECATIONS.md

What are your thoughts?

this is very well thought through from all angles, lgtm