Topic on Talk:Requests for comment/Deprecation policy

• While GitHub probably provides tools to make searching of code mirrored there easier, I'm wary about mentioning searching GitHub generically even as a "SHOULD".
• Security fixes strike me as a potential exception to this rule. Sometimes something has to be removed without warning if it's discovered to be a security issue.
• Particularly when it comes to class fields, we have many instances where things were previously no-visibility and then someone came through and marked them all public because they wanted to quickly fix "no-visibility" code sniffer warnings. gerrit:234270 cleaned up ParserOptions after one such change, it'd have been annoying to have to wait 2 release versions to deprecate them when only two things in Gerrit were using any of them.
• Other example of removing something without deprecating beforehand:
  • gerrit:236044 effectively removed some methods and fields in User (e.g. User::getPassword() and User::$mPassword). My justification was that the methods weren't even working properly in conjunction with extensions like CentralAuth and the fields should probably never have been public in the first place, and neither had much use in extensions in Gerrit.
  • gerrit:321406 got rid of the public ApiBase::$messageMap. It would have been possible to keep it, but it would have been complicated to be using it as a fallback and even more complicated to make it emit hard deprecation notices. And the public access was only used to hack around a poor interface in some hooks for which an easy alternative was available (but not really documented) since 1.27. The effort just didn't seem worth it.
• A link to a wikipage with the list of extensions and skins bundled with the tarball would be nice. Especially if there are any that aren't used on WMF wikis.

• I assume you're wary because it's not actually open source? Or because it's external? In any case, the inclusion of Github is a "let's bridge the gap and meet extension developers where they are" kind of thing - if there are other sites where there are a lot of MediaWiki extensions being hosted, we should also include it.
• I think security issues would fall under the "Removal without deprecation" section, but it still needs to be justified as the policy states.
• At this point if it's documented as "public" (as opposed to "var"), it's public, and part of the "stable API". Tim brought up something similar during the IRC meeting, so I added "or not reasonable" to the exceptions section. If core developers are fairly certain something is not being used and it's safe to make the breaking change straight away, then OK, do it, but it needs to be documented and announced properly. I think this would apply to the ApiBase::$messageMap example too.
• Will add a link to the list of bundled extensions.

To better highlight that security issues can not follow the removal process, I propose to add a header in the "Removal" section -> see my "pull request" (I wrote it on the page and undid it).

(didn’t see the RfC was in "final call")