Topic on Talk:Stable interface policy/Frontend

Currently the stable policy in the "What providers should do when removing ResourceLoader modules" section says:

"Developers MAY fix consumers of a module prior to deprecation, but doing so is not required as a precursor to deprecation."

The reasoning here was that developers should be paying attention to the developer console and the deprecation message appearing there should be sufficient to notify maintainers of their responsibility.

When deprecating, do we have more of a responsibility to fix things prior to the deprecation?

One downside of this, is deprecations would take longer and not work as they have traditionally. For example jquery.ui was deprecated 8+ years ago and consumers in Wikimedia production remain. Strengthening this to a SHOULD or MUST might make deprecations substantially more work and slower.

What do people think?

At the time of the deprecation, maybe the Tech News entry could be a MUST (even if there is no known usage, as there can be usage using string concatenation that cannot be found, or in browser scripts/browser extensions). Generally requiring MediaWiki developers to fix code at the time of deprecation is not only more work, but may also lead to worse results, as authors of the wiki-based code are probably best equipped to fix that. (In specific cases, e.g. if a module was simply renamed or merged/split, MediaWiki developers may be equipped just as well, but judging this should be up to the developers doing the deprecation. Migrating from jQuery UI to OOUI/Codex is a perfect example for a change that is better done by people who know the code: one needs to consider things OOUI/Codex doesn’t provide (non-modal windows, draggable windows etc.), things that only OOUI/Codex provides and could be taken advantage of (e.g. new input types), maybe OOUI/Codex even needs new strings that a MediaWiki developer not speaking the language cannot create, and so on.)

However, it may (or may not) make sense to require MediaWiki developers to clean up remaining known usage before completing the deprecation, as trying to use removed modules can cause serious breakage (and maybe even log spam, at least if these removed module dependencies are defined statically, in gadget definitions?). In this case, the on-wiki code being fixed by a MediaWiki developer is the alternative to it not being fixed at all and thus breaking, so from a user perspective, fixing is definitely better – the only downside is spending developers’ time that may be used more meaningfully.