I don't think this is a very good idea at all. The
real problem has to do
with
the definition of a deprecated feature. If a feature
has been deprecated,
then
it should no longer be used (at least not in the
core).
Inventing soft deprecation for features that have been superseded but have
yet
to be actually replaced is just a lazy way of putting
off fully deprecating
something. Yes, there should probably be some sort of configuration option
to
turn on/off deprecation warnings entirely, and I think
the whole
$wgDeprecationReleaseLimit is a good approach to this, but there shouldn't
be
levels of deprecation. A feature should just be
deprecated or not.
As I stated earlier, I'm pro-multiple levels of deprecation, but if we don't
go that route then I think that we should treat all deprecation the same.
This:
"Congratulations, you've just made developer warnings and your IDE's
deprecation warnings useless due to the amount of noise. These functions are
used WIDELY across the core, so deprecation should be as soft as possible. I
suggest to revert these commits (why merge them so hastily, anyway?!) and
revisit this issue when MW core and popular extensions will be (mostly)
clean."
Should not happen then if a function is deprecated. If we don't want to
display the warnings, then we shouldn't deprecate the function.
That or we need to find an alternative solution to the problem. If it makes
it any better we could call Soft Deprecation "Function Supersession" or
something similar to show that a function has been superseded even if not
formally deprecated yet.
Thank you,
Derric Atzrott