I favor deprecating functions. I'm sure you're familiar with https://xkcd.com/1172/
Have a great day, Bart Humphries [email protected] (909)529-BART(2278) <9095292278> On Tue, Jul 31, 2018 at 3:16 PM, Alex Winkler <[email protected]> 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 <[email protected]> >> 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 >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> > > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
