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!

-- 

Daniel Kinzler
Principal Software Engineer, Core Platform
Wikimedia Foundation

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to