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 <siebr...@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 <krinklem...@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: >> >> 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 > > _______________________________________________ > 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
