I favor deprecating functions. I'm sure you're familiar with
Have a great day,
On Tue, Jul 31, 2018 at 3:16 PM, Alex Winkler
> So to give my perspective as an "outsider":
> My day to day job is to write MediaWiki extensions for a wiki-farm called
> Liquipedia. We are mostly hopping LTS version, so even deprecation for two
> versions doesn't necessarily mean much to us here. Generally I just install
> a new MediaWiki version on dev and then test all of our extensions thewre
> until they work, without bothering the live version of our wikis.
> The talk here seems to be mostly about people that "blindly" upgrade their
> wiki, and I agree there will always be issues with those, no matter the
> deprecation method. If you don't update to every version, you might never
> see a deprecation notice, as the next version you are upgrading to is not
> necessarily the next version of MediaWiki released, and if you are updating
> to every version you might still not be able to fx your own extensions or
> you might not even check for deprecation notices (mind they only show up
> with the right dev params).
> I totally agree on directly removing functions that have been functionless
> for years like the one we had recently that didn't work since sometime 2009
> or so, no question about that, but I'm not so sure about working functions.
> There is a lot of consideration going into writing MediaWiki extensions,
> and there might be good reasons to not host a MediaWiki extension on
> Wikimedia git repositories. I have seen very specialized MediaWiki
> extensions that would not work without outside code (especially extensions
> allowing login with outside userdatabases and extensions querying certain
> internal APIs come to mind), so I don't think using only Wikimedia hosted
> repositories is a good indication. Generally I think deprecation periods
> that are supposed to actually be helpful should always pass at least one
> LTS release, as those reach a bigger audience.
> Deprecation wise, I personally feel like it only makes a difference if
> deprecations always survive the next LTS release, as most less regular wiki
> owners are likely to jump LTS versions. If there is no waiting for LTS
> releases, then deprecation is somewhat pointless in my point of view, since
> these policies are mostly in place for third party wikis.
> I hope this point of view is helpful to you, if there are any further
> questions regarding our own workflow, feel free to ask and I'll try to
> answer to the best of my ability.
> Alex "FO-nTTaX" Winkler
> Head of Liquipedia Development
> https://liquipedia.net/ - https://www.teamliquid.com/
> Am 31.07.2018 um 14:53 schrieb Aryeh Gregor:
>> On Tue, Jul 31, 2018 at 3:46 PM, Stephan Gambke
>>> 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
>> 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-checkin