I'm using NLog as an example here as it's the logging framework I most often use. I expect similar frameworks to have similar features.
WARNING, because it’s necessary to eventually upgrade all clients. After upgrade, this will become an error.
I see your reasoning here, and the generally used definition on what constitues a warning can arguably apply here. But I would only resort to this if it's a single warning (e.g. during startup) rather than a continual warning being spammed in the logs whenever the feature is being used.
The problems from spamming these messages (i.e. distracting from actual events) are more detrimental than the added benefit of having upgraded this message from a lower level to WARNING.
INFO, because it’s just an information.
I can somewhat follow this reasoning, but in my opinion it belongs on even lower levels (DEBUG/TRACE). This is effectively information for the developer, which is essentially what DEBUG/TRACE are built for. INFO messages are intended for developers and non-developers alike, and this message is only relevant to the developers.
Or create a custom level, if supported by the language/framework/ecosystem?
I would opt for this where available. The new level doesn't necessarily have to be on a level on its own though it certainly can be, where possible and deemed relevant).
NLog for example allows you to add different levels which behave similar to another level, but have a different name. For example, you could create a DEPRECATED level which is functionally equivalent to DEBUG.
This means that when you use level range filtering (e.g. a logger that captures from TRACE to INFO), DEPRECATED messages will always be bundled together with DEBUG messages, but the log messages themselves are labeled differently so you can quickly differentiate one from the other, e.g. if you're aware of the deprecated messages and want to filter them out for the time being.
In absence of a framework that allows you to define custom log levels, you can still resort to tagging your log messages, whether it's by prepending the DEPRECATED keyword to the log message or registering it in a custom log property (NLog allows you to pass additional values, which you could store in a separate field if you want to)