I favor deprecating functions. I'm sure you're familiar with
https://xkcd.com/1172/

Have a great day,
Bart Humphries
bart.humphr...@gmail.com
(909)529-BART(2278) <9095292278>

On Tue, Jul 31, 2018 at 3:16 PM, Alex Winkler <font...@teamliquid.net>
wrote:

> 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 <s7ep...@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.)
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to