I think this is a legal question to which the answer is probably “No”. In a scenario where you bought a commercial license to JUCE 4 and are trying to evaluate JUCE 5 and have not yet decided about it (haven’t bought a commercial license for it), you are probably not allowed to add a JUCE 5 function to JUCE 4.
How do you mean? Should separatorString and getSeparatorString() coexist without any deprecation warning? How would one know that one is already doomed for deprecation? Why do you want to get rid of a warning that’s there for a purpose?
Let’s see some examples -
A feature release may deprecate certain features from previous releases. If a feature is deprecated in feature release A.x, it will continue to work in all A.x versions (for all versions of x) but raise warnings. Deprecated features will be removed in the B.0 release, or B.1 for features deprecated in the last A.x feature release to ensure deprecations are done over at least 2 feature releases.
The warnings are silent by default. You can turn on display of these warnings with the python -Wd option.
Similar to Python’s
-Wd option, Haskell has
Turns on warnings that will be enabled by default in the future, but remain off in normal compilations for the time being. This allows library authors eager to make their code future compatible to adapt to new features before they even generate warnings.
Taking this approach, the old method can have a deprecation warning that only triggers when you enable some flag. Then at some future version this deprecation triggers by default and at a later version the old method is removed.
And to make it work best, either the deprecation cycle is extremely long as in the case of Haskell, or like in Django they maintain bugfix releases for old LTS versions, not forcing anyone to upgrade.