Thread:Project:WikiProject Extensions/Ideas/An extension migration guide?

I've noticed the interface between MediaWiki and the individual extensions appears not to be stable across revisions. Often, an extension will call some piece of core functionality or access some global which was perfectly valid in the then-current version of MediaWiki only to break once a newer MediaWiki version is released.

These issues tend to affect multiple extensions at once, for instance:
 * (1.14) Hook functions *must* return a value. Extensions written for old MW versions suddenly fail with errors if this value is omitted, even though they worked on the original targetted version of MediaWiki.
 * (1.18) $wgMessageCache->addMessage; can no longer be used to create localisable strings in MediaWiki: - this was used in quite a few old extensions from before the (whatever).i18n.php format became common and all are broken as the underlying global no longer exists.
 * (1.18) Xml::hidden used to be called from extension code in at least three or four existing extensions. The function is now Html::hidden and any code still looking for Xml::hidden is breaking.
 * (proposed for 1.20) Removal of wfLoadExtensionMessages, done here for extensions in SVN, but with no means to notify developers of other extensions that the interface has once again been changed. This may mean any new extension version that works for MW1.20-1.21+ doesn't work on MW1.15 or earlier due to lack of a consistent interface design.

At the moment, the issue is only being addressed one extension at a time, only if someone is actively maintaining the extension and (for the most part) only after things break. There is no constant, clearly-defined API to say "extensions coded to use this specific interface to MediaWiki will continue to work on all new versions"; globals may be renamed or go away entirely, callback functions may change and (because MW as deployed as source-code, not compiled) an extension author may be calling just about anything in the core code at any time.

I'd suspect there is some level of indifference on both sides - developers of core MediaWiki code and extension authors - until things break.

From the MW developer side, the extensions are often perceived as badly-written code and no surprise is expressed when things break.

The extension authors, on the other hand, likely are not following every revision posted to trunk as they merely created some small fragment of code to do a specific task on sites they are hosting - if the author is even still around. Most do not presume that an extension which works on the current MW version will be broken by a change to core code in subsequent MediaWiki versions, nor do they presume there to be much or anything that can be done to prevent this from happening.

Annoyingly, the same migration issues crop up repeatedly... but with different extensions. Each broken extension is handled (or neglected) as a separate incident, usually as a separate attempt to either debug the one among a batch of affected extensions or replace it with an equivalent. If there were one master list of changes which had broken (or will break) one or more extensions, it would be possible for someone dealing with a broken extension after upgrade to look at that guide, see "$wgMessageCache went away in 1.18 and everything using it broke, here are the alternatives to fix your extension..." without having to go through the entire revision history of MediaWiki (most of which is bug fixes and enhancements, not changes to the interface to break old extensions) to try to guess what went wrong.