Hi folks,
Per our meeting earlier today, it sounds like we want to request a delay in removing jQuery migrate. Timo's mail is included below.
Timo has staged this change here: https://gerrit.wikimedia.org/r/#/c/134607/
What day do we want to delay to? Who should make the request? Is TimedMediaHandler the main blocker, or are there others that need fixing up?
Rob ---------- Forwarded message ---------- From: Krinkle krinklemail@gmail.com Date: Wed, May 7, 2014 at 9:29 AM Subject: [Wikitech-l] Upcoming jQuery upgrade (breaking change) To: Wikimedia developers wikitech-l@lists.wikimedia.org
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
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, May 21, 2014 at 10:34 AM, Rob Lanphier robla@wikimedia.org wrote:
Hi folks,
Per our meeting earlier today, it sounds like we want to request a delay in removing jQuery migrate. Timo's mail is included below.
Timo has staged this change here: https://gerrit.wikimedia.org/r/#/c/134607/
What day do we want to delay to? Who should make the request? Is TimedMediaHandler the main blocker, or are there others that need fixing up?
MediaViewer needs to be fixed too (#590https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/590), but that's a maintained codebase and we are familiar with it, so that's not a big deal.
Based on the list of bugzilla components that send notifications to #wikimedia-multimedia (File management, GlobalUsage, ImageMap, OggHandler, PagedTiffHandler, PdfHandler, Score, TimedMediaHandler, Uploading, UploadWizard, VipsScaler, MediaViewer, CommonsMetadata) there are no more extensions to be fixed.
On Wed, May 21, 2014 at 10:48 AM, Gergo Tisza gtisza@wikimedia.org wrote:
On Wed, May 21, 2014 at 10:34 AM, Rob Lanphier robla@wikimedia.orgwrote:
Per our meeting earlier today, it sounds like we want to request a delay in removing jQuery migrate. Timo's mail is included below.
Timo has staged this change here: https://gerrit.wikimedia.org/r/#/c/134607/
What day do we want to delay to? Who should make the request? Is TimedMediaHandler the main blocker, or are there others that need fixing up?
MediaViewer needs to be fixed too (#590https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/590), but that's a maintained codebase and we are familiar with it, so that's not a big deal.
Okee doke. How much time should we ask for to fix both TMH and MediaViewer?
Rob
On Wed, May 21, 2014 at 5:42 PM, Rob Lanphier robla@wikimedia.org wrote:
Okee doke. How much time should we ask for to fix both TMH and MediaViewer?
Personally my recommendation would be to keep the jQuery backwards compatibility script until the next release branch is cut (which is in November, I think?). It does not block any further work (the upgrade already happened, the script just keeps some removed methods in existence), and for third parties who are working with the tarballs, switching from jQuery 1.8 to 1.11 without any help in transitioning will be harsh.
As far as multimedia issues are concerned: we agreed (as I understand it) to only work on TMH upgrade after the GWToolset load issues are resolved, since those actually block people from using the site, while depending on deprecated jQuery methods does not. If we want to revisit that decision, fixing TMH is probably not a huge amount of work - we could start on it now and be done by the original June 1 target date. If we stick to giving GWToolset higher priority - it's hard to estimate how long that will take. The optimistic scenario is that our current plans (rendering reference thumbnails on upload, using a reference thumbnail chain to speed up resizing and lighten the bandwidth load of scalers, use poolcounter to limit the number of expensive images that can be thumbnailed in parallel) are sufficient and turn out to be not too hard to implement, in which case... maybe a month? Gilles probably has a better grasp on the timeline. My optimistic estimates tend to be optimistic in the negative sense of the word :-)
So... Does Timo know about this conversation/requirements/request?
<quote name="Gergo Tisza" date="2014-05-22" time="14:25:38 -0700">
On Wed, May 21, 2014 at 5:42 PM, Rob Lanphier robla@wikimedia.org wrote:
Okee doke. How much time should we ask for to fix both TMH and MediaViewer?
Personally my recommendation would be to keep the jQuery backwards compatibility script until the next release branch is cut (which is in November, I think?). It does not block any further work (the upgrade already happened, the script just keeps some removed methods in existence), and for third parties who are working with the tarballs, switching from jQuery 1.8 to 1.11 without any help in transitioning will be harsh.
As far as multimedia issues are concerned: we agreed (as I understand it) to only work on TMH upgrade after the GWToolset load issues are resolved, since those actually block people from using the site, while depending on deprecated jQuery methods does not. If we want to revisit that decision, fixing TMH is probably not a huge amount of work - we could start on it now and be done by the original June 1 target date. If we stick to giving GWToolset higher priority - it's hard to estimate how long that will take. The optimistic scenario is that our current plans (rendering reference thumbnails on upload, using a reference thumbnail chain to speed up resizing and lighten the bandwidth load of scalers, use poolcounter to limit the number of expensive images that can be thumbnailed in parallel) are sufficient and turn out to be not too hard to implement, in which case... maybe a month? Gilles probably has a better grasp on the timeline. My optimistic estimates tend to be optimistic in the negative sense of the word :-)
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
On Thu, May 22, 2014 at 3:51 PM, Greg Grossmeier greg@wikimedia.org wrote:
So... Does Timo know about this conversation/requirements/request?
I'm not sure it is accurate anymore, we have just reprioritized things to have a more balanced backend/frontend work ratio, and we don't have any particularly pressing frontend technical debt fixing tasks. I'll bring up the issue with the releases on wikitech, but as I said that's a personal opinion and not related to the Multimedia team's work.
multimedia@lists.wikimedia.org