On Tue, Jul 31, 2018 at 3:46 PM, Stephan Gambke s7eph4n@protonmail.com wrote:
I agree that there is a trade-off to be done. I disagree about expecting code to be put where it is visible to core developers. I do appreciate that you go and look for where the functionality that you are working on is used outside core. But ultimately MW is publishing a public interface and it is unreasonable to expect all consumers of that interface to "register" and publish their code as well.
We don't, but if they don't publish it we have to guess at what will or won't break it, which means there's a higher chance that we will break it.
The difference is that in that case the test would have run through, throwing just a notice and the call to the deprecated function could have been removed another day.
Hard-deprecation fails the test completely, right?
Of course, if they did not want to deal with breakages, that maintainer should not have pulled MW master in the first place and should have just worked on whatever MW version they left off of a few months ago when they last worked on their extension.
Correct, we do not and should not go out of our way to make life easy for people running unstable MediaWiki. It's not meant for production unless you're following development closely and are prepared to deal with breakage.
True. I don't know how other people do it, but I usually only scan the release notes for big changes and otherwise rely on deprecation notes to pop up. Doing otherwise would require me to maintain a register of all MW core functions called from my extensions and cross-checking it by hand.
Indeed, but as soon as you see the error message, it's easy to check the release notes/history to figure out what to do. Deprecation/removal notices there should say what the replacement is as clearly as possible. (If they don't, that's a separate problem.)