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
