Hey, > However, it seems better to just delay the deprecation in core a cycle.
The policy of "half deprecating" things, by placing a detraction notice in the docs but not have a call to wfDeprecated is very flawed. Either you deprecated something or you don't. And if you do, you make sure people that want to be able to know they are using a deprecated function as soon as they do are able to. This is what makes it useful for extension developers. So, for everyone with $wgDeperectionReleaseLimit set to false, ie everyone that gets all deprecation notices, it's very useful to have a way to ignore a certain deprecated interface they can not take care of for some reason, rather then being forced to turn off deprecation warnings for everything. > Either error log settings or $wgDevelopmentWarnings can handle this. If it's to avoid them in the log, again, $wgDevelopmentWarnings works. So as I already mentioned, this would force developers from turning off the whole thing. > IMO, the notices are most useful for core & extension developers testing their code Well, obviously, this is what this setting is for. It is NOT to hide warnings on production wikis. > Yes, I read what you wrote, I just happen to disagree with you. If a bunch of extension developers maintaining extensions with wide compatibility requirements agree that this is not useful, then I'll revert myself. What I've seen so far are core developers apparently not being able to put themselves in the shoes of extension developers. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
