Developers working on MediaWiki 1.19, the latest version of the software on which Wikimedia wikis run, are now welcoming beta testers (as announced, for example, on Wikimedia Commons' village pump). According to the release's page on MediaWiki.org, it will feature improvements to the distribution of CSS styling, block log searching, timezone recognition and diff readability (as previously reported); and increased support for different relational database management systems and different languages and scripts. Over a hundred bugs are also expected to be fixed in the release (a reasonably comprehensive list of these is available).
The lengthened testing period (and more generally, the broadness with which testing is being carried out) is designed to head off the kind of implementation problems that have marked previous deployments. Work on reviewing the 1.19 code prior to deployment slowed this week, under the burden of SOPA blackout preparations. As a result, the January 31 deadline for code review will almost certainly be missed; at time of writing, 177 revisions are still in need of review compared to the target of just 44 (full chart).
The importance of 1.19 could well extend beyond its actual deployment; it is currently slated as the final SVN release before a faster, Git-based release cycle kicks in (details). As such, how well the existing process functions is likely to significantly influence the many choices that will be made during the migration to Git.
Another problematic issue of interest to wikitech-l regulars this week was referenced in a short exchange between staff developer Timo Tijhof (better known by his alias Krinkle) and bugmeister and general development process overseer Mark Hershberger. The issue centres on the tricky matter of the correct balance between backwards compatibility and modernisation in the realm of JavaScript loading.
Since the introduction of ResourceLoader in MediaWiki 1.17, core scripts and (some) gadgets are loaded as 'modules'. One of these modules is 'mw.util', on which many user scripts now rely for proper operation. The problem has arisen because, in the past, little effort was made to economise the loading of these modules, and they were assumed to be present when another script needed them (including Common.js). For the past 18 months, however, much more time has been devoted to streamlining the loading process, allowing for faster loading times and a reduced physical footprint for each page: a boon for those on slow Internet connections.
However, this improvement makes it necessary for scripts and script writers to declare which modules their script relies on (known as 'dependencies'). Officially, this has been mandatory since the introduction of ResourceLoader, but until now, these modules were already loaded by other core scripts, allowing scripts to run without errors.
Many scripts have been, or will need to be, updated to conform to the ResourceLoader specification, however. That is ultimately where the problem of backwards compatibility comes in: how to transition to the new standard while not breaking functionality of existing scripts, particularly on smaller wikis that could have lain untouched for years. "If we upgrade MediaWiki and we know that people are going to complain because a widespread dependency (like mw.util) disappeared, let's [avoid making that happen]" wrote Hershberger, "[Nobody wants a] horribly shocking experience after we upgrade the cluster". The best way to achieve that without largely nullifying the performance gains from modernisation is still being discussed (see this bug report).
Not all fixes may have gone live to WMF sites at the time of writing; some may not be scheduled to go live for many weeks.
Discuss this story
Just a small clarification I wanted to make though
The above quote is not entirely correct. Gadgets that were written before the introduction of ResourceLoader will not be affected since modules didn't exist back then, therefor they won't be affected by anything related to "dependencies" since they do not use any modules.
This matter only concerns modules created by MediaWiki extensions (including Gadgets that are using "
[ResourceLoader]" in their definition). And from those only the ones that are referring to a module in their code (such asmw.utilor$.ui.dialog) without adding the name of this module as a "required" for their module (which is done by the "dependencies=" option (more info)).Imagine a module A and B both use "jquery.ui", but only module A has this requirement declared in it's meta-data. Before MediaWiki 1.19 modules used to load a bit slower, so loading A and B (in that order) would probably not fail because B happens to be loaded after module A which already provided the "jquery.ui" functionality. In MediaWiki 1.19, however, modules are loading faster and thus make it less likely for these "lucky" hits to occur.
We acknowledge that these "lucky" hits were more common than they should be and some users have come to expect that certain modules would simply be available by default, to aid the transition we've loaded some the most popular modules by default (such as
mw.util), however other than that there isn't a whole lot we can do since there is no way of knowing which modules are needed, this is exactly where "dependencies" is for. From looking around however I see that most gadgets that use modules do have their dependency meta-data in order, it's mostly the simple few-line gadgets that emerged from copy/pasting code without including the dependency information formw.util.If anyone runs into ResourceLoader dependency-related issues on wikis in beta@wmflabs or here live post-deployment, I'd recommend you report it to mw:Talk:ResourceLoader/Migration guide (users). Krinkle (talk) 16:04, 12 February 2012 (UTC)[reply]