We have an (informal?) policy that deprecation warnings shouldn't be raised in WMF production. Thus if a core patch is going to add deprecation warnings we have to make sure that all extensions deployed on the cluster are updated to not trigger the warning. We can accomplish this by carefully managing the addition of the warnings, by detecting the core version from the extension and changing behavior, or by simply updating both core and extension at the same time. With Gerrit change 134827,[1] the affected extensions are Flow and CentralAuth. For neither of these extensions do we care that extension-master works with non-master versions of MediaWiki core, and patches to update the extensions are ready.[2][3] So normally we'd just merge all three at once and be done with it. The problem is unit tests: we can't merge the core change[1] first because Flow's unit tests will fail on the deprecation warning, and we can't merge the Flow change[2] first because it doesn't work without the core change. There are various ways to work around this, but all are ugly: 1. Merge the core change over Jenkins's objections, then the Flow change can be merged as normal. But overriding Jenkins sucks. 2. Split the core patch into two parts: part 1 does everything except add the wfDeprecated() call, while part 2 adds just the wfDeprecated() call and will be merged immediately after. The make-work here just to make Jenkins happy sucks and slightly clutters the commit history. 3. Rewrite the Flow unit test to detect whether core has the core change and alter behavior accordingly. This is even more make-work than option 2 when we're otherwise happy to just coordinate the merges. Which ugly option do we as a development community prefer in this situation? Personally I'd go for option 1 as the most expedient with the fewest long-term consequences. [1]: https://gerrit.wikimedia.org/r/#/c/134827/ [2]: https://gerrit.wikimedia.org/r/#/c/190023/ [3]: https://gerrit.wikimedia.org/r/#/c/190026/ P.S. Let's not side-track this into whether the "extension master only needs to be compatible with core master" policy for Flow and CentralAuth is good/bad, or that situations exist where options 2 or 3 are necessary choices (e.g. #2 when the extension fixes aren't ready yet and #3 when an extension involved doesn't have the "master is only compatible with core master" policy), or whether allowing core changes to be merged that cause non-WMF-deployed extensions to raise deprecation warnings is somehow discriminating against non-WMF-deployed extensions. Start a new thread if you want to discuss those, please. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation