Hello Brad,
Thank you to have taken the time to elaborate on our IRC conversation yesterday.
Le 17/06/2015 18:53, Brad Jorsch (Anomie) a écrit : <snip>
- Merge the core change over Jenkins's objections, then the Flow change
can be merged as normal. But overriding Jenkins sucks.
- 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.
Without the wfDeprecated(), the patch proposed for mediawiki/core is back compatible and the extensions tests are passing just fine. So the change is golden and can land.
Then we want to get rid of the old invocation style. One propose a change that adds the wfDeprecated(). The tests run by mediawiki-testextensions (a few dozen of extensions) are breaking. To have that change land, the extensions needs to be updated to use the new style. Since core supports the new change that is possible.
Once all extensions participating in mediawiki-testextensions are updated, the wfDeprecated() call change pass tests and can land.
With time, more extensions would be added, that would let us keeping them with mediawiki/core latest code.
- 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.
If we had a core change impacting multiple extensions, that would need a lot of work and effort. core keeping back compatibility should be enough.
cheers,