Topic on Talk:Requests for comment/Deprecation policy

Thanks for putting this together, it is much needed!

• WikiApiary.com is a UX nightmare; a more practical list of popular extensions would be nice
• how do developers notify user communities of popular extensions about breaking changes? Phabricator might not be effective; some popular extensions might not have phab tags; some popular extensions are not in gerrit so easy to miss them when reviewing what will break. Should there be a concerted effort to improve that situation? Or some "things you need to do if you want to get deprecation warnings for your extension" guideline?
• MediaWiki core code and functionality MUST NOT trigger hard deprecation warnings... - maybe a better way to put that is MediaWiki core code that triggers hard deprecation warnings must not be reachable from non-deprecated core code using non-deprecated configuration settings. Triggering warnings in B/C APIs for extensions should be fine.
• what counts as PHP API? specifically,
  • do we require depreciation for changes to old "everything is public" classes?
  • do we require depreciation for changes to protected methods? (See T146440 for a recent example of such breakage.) We do not use private visibility that much so that would in effect turn every implementation detail into an API. Can we somehow tell apart classes that you are expected to subclass and ones where you are on your own?

Thanks for the feedback :)

• I added a link to the ExtensionDistributor download stats, which could be used as another data point
• I don't really have a good idea for this. I think for practical reasons it will need to be the latter (things you need to do if you want to get deprecation warnings for your extension" guideline), which is basically 1. Mirror your extension into Gerrit, 2. Have a Phab project where people can report bugs
• Thanks, updated the wording.
• I added a "Scope" section to hopefully clarify that. The only thing I could really think of for subclassing was just making it obvious with a documentation comment, which is more conservative to the core side as effectively everything else is now "final" for the purposes of stability.

See T146440 for a recent example of such breakage - actually not an example of that. But still shows that it is easy to break subclasses with changes that you normally would not consider as changing the API.