Change 963191 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/MobileFrontend@master] Opt out of stable policy for MobileFrontend hooks, remove one

https://gerrit.wikimedia.org/r/963191

Why 1.42? WMF still uses 1.41 alphas till next week, so once 1.41 is released, all code not marked as unstable counts as being part of a public MediaWiki release, doesn’t it? Another solution would be changing the policy to explicitly state that this clause applies only to public MediaWiki releases starting with 1.42, and code made unstable between 1.41 and 1.42 counts as grandfathered.

On the other hand, third-party users may rely on code that has been part of releases before 1.42, so maybe it would be better to require both removal and making unstable to go through the deprecation process. The requirement of one month of deprecation warnings in WMF production could be lifted for these grandfathered pieces of code if they aren’t used (according to global search and code search), but the one release requirement should be kept.

On the other hand, third-party users may rely on code that has been part of releases before 1.42, so maybe it would be better to require both removal and making unstable to go through the deprecation process. The requirement of one month of deprecation warnings in WMF production could be lifted for these grandfathered pieces of code if they aren’t used (according to global search and code search), but the one release requirement should be kept.

To be clear, people responding to this ticket, should still follow the deprecation process and communication guidelines for making breaking changes. The assumption is that the earlier these APIs are clarified, the easier that might be given if APIs are not currently being used they can be removed without deprecation. Limiting APIs (by marking code accordingly) is not a breaking change.

The deadline is more social. I didn't want people to feel rushed, but I do want consumers to do this ASAP, as the earlier this is done the better, but I don't think this makes much difference on the outcome.

Does that make sense?

In T348076#9228949, @Jdlrobson wrote:

To be clear, people responding to this ticket, should still follow the deprecation process and communication guidelines for making breaking changes. The assumption is that the earlier these APIs are clarified, the easier that might be given if APIs are not currently being used they can be removed without deprecation.

Whether an API is being used can be determined only for APIs not part of any stable release, i.e. those that have been introduced during the 1.41 cycle. Probably most APIs have been introduced earlier – those need to go through the deprecation process regardless of whether they are in use on Wikimedia wikis, as we can’t determine third-party usage, don’t they?

Limiting APIs (by marking code accordingly) is not a breaking change.

It’s not a breaking change on its own, but should that previously-unlimited API be changed, that’s a breaking change, and can potentially affect usage that has been introduced prior to the code being marked unstable.

@Tacsipacsi yes to reiterate: Any breaking change must go through the deprecation cycle as outlined on https://www.mediawiki.org/wiki/Stable_interface_policy/Frontend#Deprecation_process but reviewing stable code earlier, is better for everyone as it allows us to uncover unaccounted for consumption earlier.