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