Hey all,
TL;DR: jQuery will soon be upgraded from v1.8.3 to v1.11.x (the latest). This major release removes deprecated functionality. Please migrate away from this deprecated functionality as soon as possible.
It's been a long time coming but we're now finally upgrading the jQuery package that ships with MediaWiki.
We used to regularly upgrade jQuery in the past, but got stuck at v1.8 a couple of years ago due to lack of time and concern about disruption. Because of this, many developers have needed to work around bugs that were already fixed in later versions of jQuery. Thankfully, jQuery v1.9 (and its v2 counterpart) has been the first release in jQuery history that needed an upgrade guide[1][2]. It's a major release that cleans up deprecated and dubious functionality.
Migration of existing code in extensions, gadgets, and user & site scripts should be trivial (swapping one method for another, maybe with a slight change to the parameters passed). This is all documented in the upgrade guide[1][2]. The upgrade guide may look scary (as it lists many of your favourite methods), but they are mostly just addressing edge cases.
== Call to action ==
This is a call for you, to:
1) Get familiar with http://jquery.com/upgrade-guide/1.9/.
2) Start migrating your code.
jQuery v1.9 is about removing deprecated functionality. The new functionality is already present in jQuery 1.8 or, in some cases, earlier.
3) Look out for deprecation warnings.
Once instrumentation has begun, using "?debug=true" will log jQuery deprecation warnings to the console. Look for ones marked "JQMIGRATE" [7]. You might also find deprecation notices from mediawiki.js, for more about those see the mail from last October [8].
== Plan ==
1) Instrumentation and logging
The first phase is to instrument jQuery to work out all the areas which will need work. I have started work on loading jQuery Migrate alongside the current version of jQuery. I expect that to land in master this week [6], and roll out on Wikimedia wikis the week after. This will enable you to detect usage of most deprecated functionality through your browser console. Don't forget the upgrade guide[1], as Migrate cannot detect everything.
2) Upgrade and Migrate
After this, the actual upgrade will take place, whilst Migrate stays. This should not break anything since Migrate covers almost all functionality that will be removed. The instrumentation and logging will remain during this phase; the only effective change at this point is whatever jQuery didn't think was worth covering in Migrate or were just one of many bug fixes.
3) Finalise upgrade
Finally, we will remove the migration plugin (both the Migrate compatibility layer and its instrumentation). This will bring us to a clean version of latest jQuery v1.x without compatibility hacks.
A rough timeline:
* 12 May 2014 (1.24wmf4 [9]): Phase 1 – Instrumentation and logging starts. This will run for 4 weeks (until June 9).
* 19 May 2014 (1.24wmf5): Phase 2 – "Upgrade and Migrate". This will run for 3 weeks (upto June 9). The instrumentation continues during this period.
* 1 June 2014 (1.24wmf7) Finalise upgrade.
== FAQ ==
Q: The upgrade guide is for jQuery v1.9, what about jQuery v1.10 and v1.11?
A: Those are regular updates that only fix bugs and/or introduce non-breaking enhancements. Like jQuery v1.7 and v1.8, we can upgrade to those without any hassle. We'll be fast-forwarding straight from v1.8 to v1.11.
Q: What about the jQuery Migrate plugin?
A: jQuery developed a plugin that adds back some of the removed features (not all, consult the upgrade guide[2] for details). It also logs usage of these to the console.
Q: When will the upgrade happen?
A: In the next few weeks, once we are happy that the impact is reasonably low. An update will be sent to wikitech-l just before this is done as a final reminder. This will be well before the MediaWiki 1.24 branch point for extension authors looking to maintain compatibility.
Q: When are we moving to jQuery v2.x?
A: We are not currently planing to do this. Despite the name, jQuery v2.x doesn't contain any new features compared to jQuery v1 [3]. The main difference is in the reduced support for different browsers and environments; most noticeably, jQuery 2.x drops support for Internet Explorer 8 and below, which MediaWiki is still supporting for now, and is outside the scope of this work. Both v1 and v2 continue to enjoy simultaneous releases for bug fixes and new features. For example, jQuery released v1.11 and v2.1 together[4][5].
-- Krinkle
[1] http://blog.jquery.com/2013/01/15/jquery-1-9-final-jquery-2-0-beta-migrate- final-released/ [2] http://jquery.com/upgrade-guide/1.9/ [3] http://blog.jquery.com/2013/04/18/jquery-2-0-released/ [4] http://blog.jquery.com/2014/01/24/jquery-1-11-and-2-1-released/ [5] http://blog.jquery.com/2013/05/24/jquery-1-10-0-and-2-0-1-released/ [6] https://gerrit.wikimedia.org/r/131494 [7] https://github.com/jquery/jquery-migrate/blob/master/warnings.md [8] http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg72198.html [9] https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap
Is there any way we can have a Jenkins job check for the use of deprecated and report it, or have a scan of Gerrit repos done and reports made available somewhere?
Cheers!
-- Siebrand
Op 7 mei 2014 om 18:29 heeft Krinkle krinklemail@gmail.com het volgende geschreven:
Hey all,
TL;DR: jQuery will soon be upgraded from v1.8.3 to v1.11.x (the latest). This major release removes deprecated functionality. Please migrate away from this deprecated functionality as soon as possible.
It's been a long time coming but we're now finally upgrading the jQuery package that ships with MediaWiki.
We used to regularly upgrade jQuery in the past, but got stuck at v1.8 a couple of years ago due to lack of time and concern about disruption. Because of this, many developers have needed to work around bugs that were already fixed in later versions of jQuery. Thankfully, jQuery v1.9 (and its v2 counterpart) has been the first release in jQuery history that needed an upgrade guide[1][2]. It's a major release that cleans up deprecated and dubious functionality.
Migration of existing code in extensions, gadgets, and user & site scripts should be trivial (swapping one method for another, maybe with a slight change to the parameters passed). This is all documented in the upgrade guide[1][2]. The upgrade guide may look scary (as it lists many of your favourite methods), but they are mostly just addressing edge cases.
== Call to action ==
This is a call for you, to:
Get familiar with http://jquery.com/upgrade-guide/1.9/.
Start migrating your code.
jQuery v1.9 is about removing deprecated functionality. The new functionality is already present in jQuery 1.8 or, in some cases, earlier.
- Look out for deprecation warnings.
Once instrumentation has begun, using "?debug=true" will log jQuery deprecation warnings to the console. Look for ones marked "JQMIGRATE" [7]. You might also find deprecation notices from mediawiki.js, for more about those see the mail from last October [8].
== Plan ==
- Instrumentation and logging
The first phase is to instrument jQuery to work out all the areas which will need work. I have started work on loading jQuery Migrate alongside the current version of jQuery. I expect that to land in master this week [6], and roll out on Wikimedia wikis the week after. This will enable you to detect usage of most deprecated functionality through your browser console. Don't forget the upgrade guide[1], as Migrate cannot detect everything.
- Upgrade and Migrate
After this, the actual upgrade will take place, whilst Migrate stays. This should not break anything since Migrate covers almost all functionality that will be removed. The instrumentation and logging will remain during this phase; the only effective change at this point is whatever jQuery didn't think was worth covering in Migrate or were just one of many bug fixes.
- Finalise upgrade
Finally, we will remove the migration plugin (both the Migrate compatibility layer and its instrumentation). This will bring us to a clean version of latest jQuery v1.x without compatibility hacks.
A rough timeline:
- 12 May 2014 (1.24wmf4 [9]): Phase 1 – Instrumentation and logging starts. This
will run for 4 weeks (until June 9).
- 19 May 2014 (1.24wmf5): Phase 2 – "Upgrade and Migrate". This will run for 3
weeks (upto June 9). The instrumentation continues during this period.
- 1 June 2014 (1.24wmf7) Finalise upgrade.
== FAQ ==
Q: The upgrade guide is for jQuery v1.9, what about jQuery v1.10 and v1.11?
A: Those are regular updates that only fix bugs and/or introduce non-breaking enhancements. Like jQuery v1.7 and v1.8, we can upgrade to those without any hassle. We'll be fast-forwarding straight from v1.8 to v1.11.
Q: What about the jQuery Migrate plugin?
A: jQuery developed a plugin that adds back some of the removed features (not all, consult the upgrade guide[2] for details). It also logs usage of these to the console.
Q: When will the upgrade happen?
A: In the next few weeks, once we are happy that the impact is reasonably low. An update will be sent to wikitech-l just before this is done as a final reminder. This will be well before the MediaWiki 1.24 branch point for extension authors looking to maintain compatibility.
Q: When are we moving to jQuery v2.x?
A: We are not currently planing to do this. Despite the name, jQuery v2.x doesn't contain any new features compared to jQuery v1 [3]. The main difference is in the reduced support for different browsers and environments; most noticeably, jQuery 2.x drops support for Internet Explorer 8 and below, which MediaWiki is still supporting for now, and is outside the scope of this work. Both v1 and v2 continue to enjoy simultaneous releases for bug fixes and new features. For example, jQuery released v1.11 and v2.1 together[4][5].
-- Krinkle
[1] http://blog.jquery.com/2013/01/15/jquery-1-9-final-jquery-2-0-beta-migrate- final-released/ [2] http://jquery.com/upgrade-guide/1.9/ [3] http://blog.jquery.com/2013/04/18/jquery-2-0-released/ [4] http://blog.jquery.com/2014/01/24/jquery-1-11-and-2-1-released/ [5] http://blog.jquery.com/2013/05/24/jquery-1-10-0-and-2-0-1-released/ [6] https://gerrit.wikimedia.org/r/131494 [7] https://github.com/jquery/jquery-migrate/blob/master/warnings.md [8] http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg72198.html [9] https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Is there any way to deliver the deprecation messages to a server side log? I'd rather not spend time inspecting all user scripts and gadgets manually (I'm thinking of non-WMF sites).
-Niklas
I don't think it is possible or worth the effort to scan for these in an automated fashion within Jenkins.
Static analysis is virtually impossible due to the method names being too simple, and lots of it relies on details of how methods are called, as well.
For example, "$something.error( .. )" was deprecated. Doing a static search for ".error" would yield to many false positives. And trying to parse the scripts and figure out what is and isn't a jQuery object seems like a task outside the scope here (especially considering this is a one-time migration).
Doing it via the method the migrate instrumentation uses is more reliable (though it still doesn't cover everything), but that requires execution. You'd have to somehow execute and trigger all code paths.
It would imho give a false sense of security. I'm afraid this comes down to requiring active maintenance and knowledge of the code base. While migration is simple and should not require knowledge of a module's workings, identifying them in the first place can't be done statically. Take time in the next few weeks to play with the various teams and projects you're a part of and take a few minutes to ensure there are no deprecation notices being fired when using them.
In addition, (to see if maybe you missed any) you could perform a few grep/ack searches if you want to be extra sure (manually, so that you can mentally exclude false positives).
— Krinkle
On 7 May 2014, at 19:27, Siebrand Mazeland siebrand@kitano.nl wrote:
Is there any way we can have a Jenkins job check for the use of deprecated and report it, or have a scan of Gerrit repos done and reports made available somewhere?
Cheers!
-- Siebrand
Op 7 mei 2014 om 18:29 heeft Krinkle krinklemail@gmail.com het volgende geschreven:
Hey all,
TL;DR: jQuery will soon be upgraded from v1.8.3 to v1.11.x (the latest). This major release removes deprecated functionality. Please migrate away from this deprecated functionality as soon as possible.
It's been a long time coming but we're now finally upgrading the jQuery package that ships with MediaWiki.
We used to regularly upgrade jQuery in the past, but got stuck at v1.8 a couple of years ago due to lack of time and concern about disruption. Because of this, many developers have needed to work around bugs that were already fixed in later versions of jQuery. Thankfully, jQuery v1.9 (and its v2 counterpart) has been the first release in jQuery history that needed an upgrade guide[1][2]. It's a major release that cleans up deprecated and dubious functionality.
Migration of existing code in extensions, gadgets, and user & site scripts should be trivial (swapping one method for another, maybe with a slight change to the parameters passed). This is all documented in the upgrade guide[1][2]. The upgrade guide may look scary (as it lists many of your favourite methods), but they are mostly just addressing edge cases.
== Call to action ==
This is a call for you, to:
Get familiar with http://jquery.com/upgrade-guide/1.9/.
Start migrating your code.
jQuery v1.9 is about removing deprecated functionality. The new functionality is already present in jQuery 1.8 or, in some cases, earlier.
- Look out for deprecation warnings.
Once instrumentation has begun, using "?debug=true" will log jQuery deprecation warnings to the console. Look for ones marked "JQMIGRATE" [7]. You might also find deprecation notices from mediawiki.js, for more about those see the mail from last October [8].
== Plan ==
- Instrumentation and logging
The first phase is to instrument jQuery to work out all the areas which will need work. I have started work on loading jQuery Migrate alongside the current version of jQuery. I expect that to land in master this week [6], and roll out on Wikimedia wikis the week after. This will enable you to detect usage of most deprecated functionality through your browser console. Don't forget the upgrade guide[1], as Migrate cannot detect everything.
- Upgrade and Migrate
After this, the actual upgrade will take place, whilst Migrate stays. This should not break anything since Migrate covers almost all functionality that will be removed. The instrumentation and logging will remain during this phase; the only effective change at this point is whatever jQuery didn't think was worth covering in Migrate or were just one of many bug fixes.
- Finalise upgrade
Finally, we will remove the migration plugin (both the Migrate compatibility layer and its instrumentation). This will bring us to a clean version of latest jQuery v1.x without compatibility hacks.
A rough timeline:
- 12 May 2014 (1.24wmf4 [9]): Phase 1 – Instrumentation and logging starts. This
will run for 4 weeks (until June 9).
- 19 May 2014 (1.24wmf5): Phase 2 – "Upgrade and Migrate". This will run for 3
weeks (upto June 9). The instrumentation continues during this period.
- 1 June 2014 (1.24wmf7) Finalise upgrade.
== FAQ ==
Q: The upgrade guide is for jQuery v1.9, what about jQuery v1.10 and v1.11?
A: Those are regular updates that only fix bugs and/or introduce non-breaking enhancements. Like jQuery v1.7 and v1.8, we can upgrade to those without any hassle. We'll be fast-forwarding straight from v1.8 to v1.11.
Q: What about the jQuery Migrate plugin?
A: jQuery developed a plugin that adds back some of the removed features (not all, consult the upgrade guide[2] for details). It also logs usage of these to the console.
Q: When will the upgrade happen?
A: In the next few weeks, once we are happy that the impact is reasonably low. An update will be sent to wikitech-l just before this is done as a final reminder. This will be well before the MediaWiki 1.24 branch point for extension authors looking to maintain compatibility.
Q: When are we moving to jQuery v2.x?
A: We are not currently planing to do this. Despite the name, jQuery v2.x doesn't contain any new features compared to jQuery v1 [3]. The main difference is in the reduced support for different browsers and environments; most noticeably, jQuery 2.x drops support for Internet Explorer 8 and below, which MediaWiki is still supporting for now, and is outside the scope of this work. Both v1 and v2 continue to enjoy simultaneous releases for bug fixes and new features. For example, jQuery released v1.11 and v2.1 together[4][5].
-- Krinkle
[1] http://blog.jquery.com/2013/01/15/jquery-1-9-final-jquery-2-0-beta-migrate- final-released/ [2] http://jquery.com/upgrade-guide/1.9/ [3] http://blog.jquery.com/2013/04/18/jquery-2-0-released/ [4] http://blog.jquery.com/2014/01/24/jquery-1-11-and-2-1-released/ [5] http://blog.jquery.com/2013/05/24/jquery-1-10-0-and-2-0-1-released/ [6] https://gerrit.wikimedia.org/r/131494 [7] https://github.com/jquery/jquery-migrate/blob/master/warnings.md [8] http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg72198.html [9] https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap
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
Op 14 mei 2014 om 14:58 heeft Krinkle krinklemail@gmail.com het volgende geschreven:
I don't think it is possible or worth the effort to scan for these in an automated fashion within Jenkins.
Static analysis is virtually impossible due to the method names being too simple, and lots of it relies on details of how methods are called, as well.
At translatewiki.net, we log client side issues using a script[1]. Might something like that be of any benefit?
[1] http://git.wikimedia.org/blob/translatewiki.git/HEAD/webfiles%2Ftwn.jserrorl...
-- Siebrand
That's an entirely different thing from scanning or catching things in development. That's harvesting from clients in production. That is certainly possible, and Wikimedia does that, too.
Deprecated properties[1], and features[2] use mw.track[3] to emit an event.
And the WikimediaEvents extension forwards these to EventLogging (at a sampled rate of course). Which are then available privately in the analytics database, and made available anonymised in Graphite[5].
You can set up similar logging for JQMIGRATE. Note though that jQuery Migrate doesn't have nice keys, you'll have to do with the full descriptive sentence of the warning (but you're doing that already at TWN).
You could try something like this:
if ( jQuery.migrateWarnings ) { jQuery.migrateWarnings.push = function (msg) { mw.twn.log( '/webfiles/jswarning', { msg: '[jquery.migrate]' + msg, stack: new Error().stack } ); }; }
I might set up some tracking for it at Wikimedia as well, but I'm not sure if that'll work properly.
— Krinkle
[1] https://github.com/wikimedia/mediawiki-core/blob/wmf/1.24wmf4/resources/src/... [2] https://github.com/wikimedia/mediawiki-core/blob/wmf/1.24wmf4/resources/src/... [3] https://github.com/wikimedia/mediawiki-core/blob/wmf/1.24wmf4/resources/src/... [4] https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/blob/maste... [5] http://codepen.io/Krinkle/full/zyodJ/
On 14 May 2014, at 19:07, Siebrand Mazeland siebrand@kitano.nl wrote:
Op 14 mei 2014 om 14:58 heeft Krinkle krinklemail@gmail.com het volgende geschreven:
I don't think it is possible or worth the effort to scan for these in an automated fashion within Jenkins.
Static analysis is virtually impossible due to the method names being too simple, and lots of it relies on details of how methods are called, as well.
At translatewiki.net, we log client side issues using a script[1]. Might something like that be of any benefit?
[1] http://git.wikimedia.org/blob/translatewiki.git/HEAD/webfiles%2Ftwn.jserrorl...
-- Siebrand _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 05/14/2014 01:07 PM, Siebrand Mazeland wrote:
Op 14 mei 2014 om 14:58 heeft Krinkle krinklemail@gmail.com het volgende geschreven:
I don't think it is possible or worth the effort to scan for these in an automated fashion within Jenkins.
Static analysis is virtually impossible due to the method names being too simple, and lots of it relies on details of how methods are called, as well.
At translatewiki.net, we log client side issues using a script[1]. Might something like that be of any benefit?
That's catching actual errors in production, which is definitely suboptimal compared to catching it during development/maintenance. However, it's better than not catching it at all until a technical user notices and reports the bug.
Matt Flaschen
On Wed, May 7, 2014 at 9:29 AM, Krinkle krinklemail@gmail.com wrote:
A rough timeline:
- 12 May 2014 (1.24wmf4 [9]): Phase 1 – Instrumentation and logging
starts. This will run for 4 weeks (until June 9).
- 19 May 2014 (1.24wmf5): Phase 2 – "Upgrade and Migrate". This will run
for 3 weeks (upto June 9). The instrumentation continues during this period.
- 1 June 2014 (1.24wmf7) Finalise upgrade.
(...)
Q: When will the upgrade happen?
A: In the next few weeks, once we are happy that the impact is reasonably low. An update will be sent to wikitech-l just before this is done as a final reminder. This will be well before the MediaWiki 1.24 branch point for extension authors looking to maintain compatibility.
I'm not sure this decision makes sense. This would mean that 1.23 shipped with jQuery 1.8 and 1.24 will ship with jQuery 1.11, without the backwards compatibility plugin. I don't see how this helps extension authors, and it will be a nuisance for wiki webmasters who will have to deal with the breakage of all the not-so-well maintained extensions, without any transition period where they could identify and fix/replace them, when they do the 1.23 -> 1.24 upgrade. There should be a major version which includes the migration plugin.
(This is a separate matter from whn the migration plugin should be removed from WMF-maintained sites. It adds to the JS overhead, even if just a little, and it might make sense to put jQuery Migrate behind a config switch which is enabled by default but disabled on Wikimedia sites after June 1. But the next tarball should contain the migration plugin and enable it by default.)
On 22 May 2014 18:11, Gergo Tisza gtisza@wikimedia.org wrote:
On Wed, May 7, 2014 at 9:29 AM, Krinkle krinklemail@gmail.com wrote:
> Q: When will the upgrade happen?
A: In the next few weeks, once we are happy that the impact is reasonably low. An update will be sent to wikitech-l just before this is done as a
final
reminder.
This will be well before the MediaWiki 1.24 branch point for
extension authors looking to maintain compatibility.
I'm not sure this decision makes sense. This would mean that 1.23 shipped with jQuery 1.8 and 1.24 will ship with jQuery 1.11, without the backwards compatibility plugin. I don't see how this helps extension authors, and it will be a nuisance for wiki webmasters who will have to deal with the breakage of all the not-so-well maintained extensions, without any transition period where they could identify and fix/replace them, when they do the 1.23 -> 1.24 upgrade. There should be a major version which includes the migration plugin.
Possibly, though I would suggest that it is not loaded by default. Frankly if an extension's authors have abandoned their extension to the extent that after several years' clear warning and a six month-long notice period they still didn't do a relatively trivial set of fixes, then it's reasonable to make it necessary for sysadmins to make a (small) effort acknowledging that this code is toxic and should only be used if you're willing to wade into "here be dragons" territory.
Indeed, I created this patch for this purpose, which retains jQuery.Migrate (with the intent to remove it for MediaWiki 1.25):
https://gerrit.wikimedia.org/r/#/c/133719/%E2%80%8B
(This is a separate matter from whn the migration plugin should be removed from WMF-maintained sites. It adds to the JS overhead, even if just a little, and it might make sense to put jQuery Migrate behind a config switch which is enabled by default but disabled on Wikimedia sites after June 1. But the next tarball should contain the migration plugin and enable it by default.)
I disagree, for the reasons stated above; the inverse makes more sense.
J.
On 05/22/2014 09:25 PM, James Forrester wrote:
Possibly, though I would suggest that it is not loaded by default. Frankly if an extension's authors have abandoned their extension to the extent that after several years' clear warning and a six month-long notice period they still didn't do a relatively trivial set of fixes, then it's reasonable to make it necessary for sysadmins to make a (small) effort acknowledging that this code is toxic and should only be used if you're willing to wade into "here be dragons" territory.
What notice period are you referring to?
Matt Flaschen
On 3 June 2014 17:01, Matthew Flaschen mflaschen@wikimedia.org wrote:
On 05/22/2014 09:25 PM, James Forrester wrote:
Possibly, though I would suggest that it is not loaded by default. Frankly if an extension's authors have abandoned their extension to the extent that after several years' clear warning and a six month-long notice period they still didn't do a relatively trivial set of fixes, then it's reasonable to make it necessary for sysadmins to make a (small) effort acknowledging that this code is toxic and should only be used if you're willing to wade into "here be dragons" territory.
What notice period are you referring to?
I don't recall; probably the announcement at the architecture summit?
There have been a number of high-profile semi-announcements as well as comments and code reviews relating to this, most obviously this one:
http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064280.html%E2...
J.
On 06/03/2014 09:04 PM, James Forrester wrote:
There have been a number of high-profile semi-announcements as well as comments and code reviews relating to this, most obviously this one:
http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064280.html%E2...
True, that's only one piece ($.browser) of it, though.
Matt Flaschen
On 23 May 2014, at 03:11, Gergo Tisza gtisza@wikimedia.org wrote:
On Wed, May 7, 2014 at 9:29 AM, Krinkle krinklemail@gmail.com wrote:
A rough timeline:
- 12 May 2014 (1.24wmf4 [9]): Phase 1 – Instrumentation and logging
starts. This will run for 4 weeks (until June 9).
- 19 May 2014 (1.24wmf5): Phase 2 – "Upgrade and Migrate". This will run
for 3 weeks (upto June 9). The instrumentation continues during this period.
- 1 June 2014 (1.24wmf7) Finalise upgrade.
(...) Q: When will the upgrade happen? A: In the next few weeks, once we are happy that the impact is reasonably low. An update will be sent to wikitech-l just before this is done as a final reminder. This will be well before the MediaWiki 1.24 branch point for extension authors looking to maintain compatibility.
I'm not sure this decision makes sense. This would mean that 1.23 shipped with jQuery 1.8 and 1.24 will ship with jQuery 1.11, without the backwards compatibility plugin. I don't see how this helps extension authors, and it will be a nuisance for wiki webmasters who will have to deal with the breakage of all the not-so-well maintained extensions, without any transition period where they could identify and fix/replace them, when they do the 1.23 -> 1.24 upgrade. There should be a major version which includes the migration plugin.
I disagree. These jQuery features were deprecated many years ago.
jQuery.browser was deprecated in 1.3.0[1][2] * 2009-01 (over 5 years ago) * MediaWiki 1.16 shipped jQuery v1.3.2
jQuery#live was deprecated in 1.7.0[3][4] * 2011-11 (over 2 years ago) * MediaWiki 1.19 shipped jQuery 1.7.1
Etc. etc.
They've been deprecated for a long time now (at least one or three major releases). So it's not like it all came out of nowhere. These are not deprecations, it's the removal of deprecated features.
MediaWiki 1.24 is a major release and this major change (potentially breaking change) has appropriate release notes. I don't think there is an obligation here to maintain compatibility with extensions yet another release.
Extensions are branched at the same time as core. There is no assumption that an unmaintained extension will remain working with a newer MediaWiki core version (practically every release we have a few minor breaking changes that require changes to extensions, this is no different).
Also, shipping with the Migrate extension is essentially just shipping the old version of jQuery. We've been doing that already since MediaWiki 1.21 by simply not upgrading jQuery. It's been several releases since; that time is over now.
In addition, I think it's a bad idea to release MediaWiki with the Migrate plugin enabled by default. Is an odd environment to provide/support (a bit like trying to support IE8 in IE7 compat mode; people have a hard enough time already with different IE versions, avoid mutations if possible).
See also my comments on https://gerrit.wikimedia.org/r/#/c/133719/
-- Krinkle
[1] http://blog.jquery.com/2009/01/14/jquery-1-3-released/ [2] http://api.jquery.com/category/deprecated/deprecated-1.3/ [3] http://blog.jquery.com/2011/11/03/jquery-1-7-released/ [4] http://api.jquery.com/category/deprecated/deprecated-1.7/
Hey all,
TL;DR: * We did not make the breaking change last week for Wikimedia; it is postponed. * MediaWiki 1.24.0 will ship with jQuery Migrate switched off. * Wikimedia & non-Wikimedia wikis can enable jQuery Migrate if needed. * When MediaWiki 1.24 is released, we will switch off jQuery Migrate for Wikimedia wikis.
As we said last month, we are upgrading MediaWiki's jQuery to version 1.11.x [1], which removes some long-deprecated functions. These were done in phase one [2] and two [3] as of last week.
However, we have held off with phase 3 (removing the jQuery Migrate plugin) for a while to give migration a little more time.
The amount of migration work necessary has been much less than I anticipated. Very few scripts have actually needed changing, probably because these features have been deprecated for quite a while now. Some of newer developers may never have even known of these APIs.
Having said that, it does take a while for a message like this to spread out to some members of our large community. While those wiki scripts and gadgets which have active maintainers have been looked into, and (where needed) updated accordingly, a large number of gadgets and scripts in the cluster of Wikimedia wikis have not yet had a chance to get a grip on this, let alone extensions and wikis outside of Wikimedia.
While I don't want to set another deadline, I think it makes sense to ship the jQuery Migrate plugin for one release (with MediaWiki 1.24), and then remove it in MediaWiki 1.25. This will give all wikis' communities and extension authors a few more months until the MediaWiki 1.24 branch point (in Autumn 2014) before they will need to make adjustments to work with MediaWiki master.
MediaWiki 1.24.0 stable will disable support for legacy jQuery by default. If you find you have scripts, gadgets or extensions still using legacy jQuery APIs, you can enable them with a simple line in LocalSettings.php:
$wgIncludejQueryMigrate = true;
And of course when you find you need to do this, please make an effort to ensure the maintainers of those items still using these legacy features are aware of this so they may patch the code accordingly (using the upgrade guide[4] and my earlier announcement [5]). When MediaWiki 1.24 is released, we will switch off jQuery Migrate for Wikimedia wikis.
— Krinkle
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=44740 [2] https://gerrit.wikimedia.org/r/#/c/131494/ [3] https://gerrit.wikimedia.org/r/#/c/133477/ [4] http://jquery.com/upgrade-guide/1.9/ [5] http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg75735.html
On 7 May 2014, at 18:29, Krinkle krinklemail@gmail.com wrote:
Hey all,
TL;DR: jQuery will soon be upgraded from v1.8.3 to v1.11.x (the latest). This major release removes deprecated functionality. Please migrate away from this deprecated functionality as soon as possible.
It's been a long time coming but we're now finally upgrading the jQuery package that ships with MediaWiki.
We used to regularly upgrade jQuery in the past, but got stuck at v1.8 a couple of years ago due to lack of time and concern about disruption. Because of this, many developers have needed to work around bugs that were already fixed in later versions of jQuery. Thankfully, jQuery v1.9 (and its v2 counterpart) has been the first release in jQuery history that needed an upgrade guide[1][2]. It's a major release that cleans up deprecated and dubious functionality.
Migration of existing code in extensions, gadgets, and user & site scripts should be trivial (swapping one method for another, maybe with a slight change to the parameters passed). This is all documented in the upgrade guide[1][2]. The upgrade guide may look scary (as it lists many of your favourite methods), but they are mostly just addressing edge cases.
== Call to action ==
This is a call for you, to:
Get familiar with http://jquery.com/upgrade-guide/1.9/.
Start migrating your code.
jQuery v1.9 is about removing deprecated functionality. The new functionality is already present in jQuery 1.8 or, in some cases, earlier.
- Look out for deprecation warnings.
Once instrumentation has begun, using "?debug=true" will log jQuery deprecation warnings to the console. Look for ones marked "JQMIGRATE" [7]. You might also find deprecation notices from mediawiki.js, for more about those see the mail from last October [8].
== Plan ==
- Instrumentation and logging
The first phase is to instrument jQuery to work out all the areas which will need work. I have started work on loading jQuery Migrate alongside the current version of jQuery. I expect that to land in master this week [6], and roll out on Wikimedia wikis the week after. This will enable you to detect usage of most deprecated functionality through your browser console. Don't forget the upgrade guide[1], as Migrate cannot detect everything.
- Upgrade and Migrate
After this, the actual upgrade will take place, whilst Migrate stays. This should not break anything since Migrate covers almost all functionality that will be removed. The instrumentation and logging will remain during this phase; the only effective change at this point is whatever jQuery didn't think was worth covering in Migrate or were just one of many bug fixes.
- Finalise upgrade
Finally, we will remove the migration plugin (both the Migrate compatibility layer and its instrumentation). This will bring us to a clean version of latest jQuery v1.x without compatibility hacks.
A rough timeline:
- 12 May 2014 (1.24wmf4 [9]): Phase 1 – Instrumentation and logging starts. This
will run for 4 weeks (until June 9).
- 19 May 2014 (1.24wmf5): Phase 2 – "Upgrade and Migrate". This will run for 3
weeks (upto June 9). The instrumentation continues during this period.
- 1 June 2014 (1.24wmf7) Finalise upgrade.
== FAQ ==
Q: The upgrade guide is for jQuery v1.9, what about jQuery v1.10 and v1.11?
A: Those are regular updates that only fix bugs and/or introduce non-breaking enhancements. Like jQuery v1.7 and v1.8, we can upgrade to those without any hassle. We'll be fast-forwarding straight from v1.8 to v1.11.
Q: What about the jQuery Migrate plugin?
A: jQuery developed a plugin that adds back some of the removed features (not all, consult the upgrade guide[2] for details). It also logs usage of these to the console.
Q: When will the upgrade happen?
A: In the next few weeks, once we are happy that the impact is reasonably low. An update will be sent to wikitech-l just before this is done as a final reminder. This will be well before the MediaWiki 1.24 branch point for extension authors looking to maintain compatibility.
Q: When are we moving to jQuery v2.x?
A: We are not currently planing to do this. Despite the name, jQuery v2.x doesn't contain any new features compared to jQuery v1 [3]. The main difference is in the reduced support for different browsers and environments; most noticeably, jQuery 2.x drops support for Internet Explorer 8 and below, which MediaWiki is still supporting for now, and is outside the scope of this work. Both v1 and v2 continue to enjoy simultaneous releases for bug fixes and new features. For example, jQuery released v1.11 and v2.1 together[4][5].
-- Krinkle
[1] http://blog.jquery.com/2013/01/15/jquery-1-9-final-jquery-2-0-beta-migrate- final-released/ [2] http://jquery.com/upgrade-guide/1.9/ [3] http://blog.jquery.com/2013/04/18/jquery-2-0-released/ [4] http://blog.jquery.com/2014/01/24/jquery-1-11-and-2-1-released/ [5] http://blog.jquery.com/2013/05/24/jquery-1-10-0-and-2-0-1-released/ [6] https://gerrit.wikimedia.org/r/131494 [7] https://github.com/jquery/jquery-migrate/blob/master/warnings.md [8] http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg72198.html [9] https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap
Hey all,
On 3 Jun 2014, Krinkle wrote:
TL;DR:
- We did not make the breaking change last week for Wikimedia; it is postponed.
- MediaWiki 1.24.0 will ship with jQuery Migrate switched off.
- Wikimedia & non-Wikimedia wikis can enable jQuery Migrate if needed.
- When MediaWiki 1.24 is released, we will switch off jQuery Migrate for Wikimedia wikis.
This is now due. [0]
The change [1] will land in master after the branch cut next week. It will roll out in 1.25wmf12, which will be deployed to Wikimedia wikis starting Wednesday 10 December: [1]
* It will affect mediawiki.org and test wikis on Wednesday 10 December. * It will affect sister projects on Tuesday 16 December. * It will affect Wikipedias on Wednesday 17 December.
For non-Wikimedia wikis, this will ship in MediaWiki 1.25.0.
Thanks for all the help so far!
Best,
— Krinkle
[0] https://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg76236.html [1] https://gerrit.wikimedia.org/r/#/c/137168/ [2] https://www.mediawiki.org/wiki/MediaWiki_1.25/Roadmap
wikitech-l@lists.wikimedia.org