Hi all!

In August, I wrote to this list to discuss the when and how breaking changes can be made without deprecation https://lists.wikimedia.org/pipermail/wikitech-l/2020-August/093761.html. The proposal I made at the time was admittedly rather radical, but it lead of a good discussion and flushed out a number of pain points and interesting ideas. Based on this discussion and other feedback, I have drafted an update to the Stable Interface Policy. You can find it here:

User:DKinzler_(WMF)/Stable_interface_policy https://www.mediawiki.org/wiki/User:DKinzler_(WMF)/Stable_interface_policy (diff https://www.mediawiki.org/w/index.php?title=User:DKinzler_(WMF)/Stable_interface_policy&type=revision&diff=4258989&oldid=4242722&diffmode=source)

The draft has entered the RFC process https://phabricator.wikimedia.org/T268326, and I intended to move it through swiftly, so it can be adopted soon. If you have any thoughts or feedback, please reply to this email, or put it on the phab task.

I would like to highlight a few of the changes that I am proposing:

* Define the idea of a MediaWiki "ecosystem", and state that extensions in this ecosystem should receive support in dealing with upcoming breaking changes. The ecosystem includes actively maintained extensions hosted by Wikimedia or listed by the MediaWiki Stakeholder Group. * Clarify that removal without deprecation is only ok for code that has never been used elsewhere. * Allow "hard deprecation by announcement" when it is not possible to emit deprecation warnings. This was previously stated as an exception from the deprecation policy, rather than a mode of deprecation. * Clarify that individuals or teams who deprecate code commit to removing usages of that code asap at least in code maintained by Wikimedia, and should support 3rd parties in this removal from code in the ecosystem. * Remove the recommendation that hard-deprecated code should be kept for two releases. This is replaced by a requirement to keep it for one release, and three months on master. * Clarify that deprecation and removal of deprecated code should not be backported to release candidates, and should ideally happen right after a release, rather than shortly before a release.

The intent is to streamline the deprecation process, ensuring that deprecated code becomes unused quickly, without causing too much of a disturbance.

Besides this, the proposal contains a number of other additions and clarifications, as described on the phab ticket and visible in the diff.

I'm looking forward to hearing your thoughts and ideas!