Jeroen De Dauw <jeroendedauw(a)gmail.com> wrote: Jeroen, I am sorry about the misquote. I should have quoted the full text. I apologize :-\ -- Antoine "hashar" Musso

Hey, revert Did you read what I wrote? How is it not useful? Please provide REASONING, that proves my argument is invalid. If you cannot do this, you have no valid reason for shouting -1. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --

Hey, 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. 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. their code Well, obviously, this is what this setting is for. It is NOT to hide warnings on production wikis. 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. --

Hey, you can't prove me wrong then it stays." Sure. If I think something is good and everyone else it's not, bad luck for me. This feature is primarily useful for extension developers, not so much for core developers. So what we got here is a bunch of core developers saying it's not so useful. Is that surprising? No, not really, I've seen this many times before (just think about the @since tag which just got ridiculed by several core developers but makes a huge difference to extension developers). What I am asking is to keep in mind the needs of developers that do not just work on core or extension with loose or no compat restraints. If it turns out that these people disagree with me, then again, bad luck for me. But I really doubt this is the case. This setting is thought useful by the two most active extension developers. That might just mean something? Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --

Hey, I fully agree it is not. Why would you do this? If an extension author has no time to update something, this should not affect deprecation policy in core. There might be exceptions, but in general this seems like a dumb thing to do. I ran into it 3 times in the last 2 months and have 3 methods whitelisted in localsettings which I'll take care off later. It is not rare if you are about forward compatibility. Right now I have everything compatible with trunk except these 3. Without this whitelist I'd have to turn off warnings for 1.19 to be able to use my wiki without getting a pile of notices every time, in which case I'd not know yet about several changes I've already taken care off now. Note how the frequency of these whitelisted methods does not matter. One is enough to make you swicth to a not as good configured dev environment. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --

On 11 January 2012 19:04, Aaron Schulz <aschulz4587(a)gmail.com> wrote: I generally agree that this is not a good addition. If a developer suppresses warnings, he will then proceed to forget about the warning that was suppressed, that's just a simple fact of life. Then the whole benefit of the warning system is negated; the developer is just as likely to update their version and find that things break as if they had turned off deprecation warnings altogether. Rather, if a developer upgrades from 1.16 to 1.17 and notices a new interface and a @deprecated warning on the old one, concludes that he cannot fix it until 1.19 is released and he can drop support for 1.16, then upgrades to 1.18 and starts getting warnings, he should hack core to remove the wfDeprecated statement from the old interface. Then when he upgrades to 1.19, the probably-now-forgotten hack is overwritten and the warnings reappear, reminding him that he should now start seriously thinking about reworking the extension code. He can then update, test and release a 1.19-compatible version of the extension before the core function itself is removed in 1.20. --HM