Thread:Talk:ResourceLoader/JavaScript Deprecations/Deprecation plan


 * See also 29753

The original plan (as somewhat documented on pages like ResourceLoader/JavaScript Deprecations) was as following:

1) Deprecation 2) Migration 3) Quarantine 4) Removal of legacy code entirely.
 * Baptize scripts in /skins/common deprecated (wikbits.js, ajax.js etc.; "legacy JS")
 * Start working on mediawiki object library
 * Work step-by-step on removing any and all references to legacy JS in MediaWiki core by either superseding/rewriting/modernizing them with new utilities in the mw object or by replacing them with calls to jQuery core or plugin methods.
 * End up in a situation where there are no references to legacy JS in MediaWiki core anymore. At this point all of it's functionality will be redundant or made possible by other means (jQuery core, plugins or mediawiki object). However at this point, all of the legacy functionality should still be available and work like it did before.
 * At this point users should start en-mass with migrating scripts (1.17 deployment). It will be highly encouraged to switch to more modern implementations of legacy features as soon as possible.
 * After a few releases (around 1.20 branch?) the legacy JS will be moved from the global scope into a quarantined scope in mw.legacy. Remapping may be used as a stop-gap until for example pending bugs in mediawiki lib are being fixed or other issues solved. Stop-gap being replacing calls from foo with mw.legacy.foo etc.

There are many scripts using things like addPortletlink, sajax_*, updateTooltipAccessKeys, checkboxShiftClick and more. While I agree that having code like this, code that is not used in core, has a future version that is said to be better and mostly compatible, etc, sounds weird.

But removing a legacy method as soon as there is a better version and telling users to fix their scripts doesn't like a plan either, see the above.