Side note. Multiple versions of jQuery can live happily on the same page. jQuery handles isolation and noConflict so well that it can work on the same page as incompatible versions of itself (which isn't the case for basically any other js library, 90% of which prototype stuff in).
I like to use a variable like `jQuery13`, basically saving the jQuery variable in an alternate variable identified by major version number. Should an upgrade come along it's a little easier to migrate code.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Tim Starling wrote:
Michael Dale wrote:
That is part of the idea of centrally hosting reusable client-side components so we control the jquery version and plugin set. So a new version won't "come along" until its been tested and integrated.
You can't host every client-side component in the world in a subdirectory of the MediaWiki core. Not everyone has commit access to it. Nobody can hope to properly test every MediaWiki extension.
Most extension developers write an extension for a particular site, and distribute their code as-is for the benefit of other users. They have no interest in integration with the core. If they find some jQuery plugin on the web that defines an interface that conflicts with MediaWiki, say jQuery.load() but with different parameters, they're not going to be impressed when you tell them that to make it work with MediaWiki, they need to rewrite the plugin and get it tested and integrated.
Different modules should have separate namespaces. This is a key property of large, maintainable systems of code. ... -- Tim Starling