On 5 April 2014 08:17, Jeroen De Dauw jeroendedauw@gmail.com wrote:

Hey,

Is anyone working on resolving this issue?

​What issue?​

The current state means that ​ ​ extension authors need to either

• use if-else checks based on MediaWiki versions
• live with having deprecation notices on 1.23
• break compatibility with 1.22 and earlier

Or am I missing something?

​Yes. You're meant to:

- write your extension for $CURRENTVERSION; - Note that extensions are branched automatically when $CURRENTVERSION increments - users use the extension's branched version (e.g. REL1_22) for $THEIRVERSION; and - backport really urgent fixes from $CURRENTVERSION to old versions.

If you *also* want to backport bug fixes and new functionality to older branched versions, that's great, but a lot of work. You may need to version each release branch for sanity if you have lots of these. It's generally worthwhile prioritising bug fixes over new functionality, and prioritising support for the versions of the extension matching the LTS versions of MediaWiki, as that is likely to be where many downstream users are.

J.

On Apr 5, 2014 1:09 PM, "Jeroen De Dauw" jeroendedauw@gmail.com wrote:

Hey,

Yes. You're meant to:

...

• write your extension for $CURRENTVERSION;

So does this mean extension authors are not supposed to write extensions compatible with multiple MediaWiki versions?

Well lots of people use separate branches for different versions of MW (including in particular the WMF). However i personally wouldn't want to try and force a particular development strategy on extension developers unless we had to, and from what I understand SMW folks have generally liked the one extension working with multiple mediawiki apptoach (I think, you would know better than me).

To clarify, in this particular issue, what would you like to be done to address it? Are you simply looking for a revert, or is there some middle ground that would make both you and the people behind the patch happy. At this stage (just imho) I dont think I would support a revert because while annoying, its not horrendously annoying and the patch has been there for a while. However if there is something we could do to make this less annoying to people with your use case, while still accomplishing the point of the patch, that would be great.

--bawolff

On 05.04.2014, 21:27 Jeroen wrote:

Hey,

...

Are you simply looking for a revert

Not of the whole commit. Just the wfDeprecated call.

I seem to remember that at one point the policy was to add a @deprecated tag, and then two releases later or so add the wfDeprecated call. Actually I made some commits which violated this policy and then got reverted.

With this approach extension authors can retain compatibility with the last few versions without doing ugly things and without running into piles of notices. Then when 1.25 comes they can do a search and replace and bump their min mw version to 1.23. That saves both the extension devs a lot of hassle, and does not throw the users of those extensions under the bus either.

Sounds reasonable to me --> https://gerrit.wikimedia.org/r/124130

I know the wfDeprecated() has already been removed, but anyway…

Couldn't you just create a MyExtensionNameSpecialPage class like below and extend that for your special pages instead of regular SpecialPage, which would let you always call the non-deprecated getPageTitle() instead of getTitle() even on ancient MediaWiki versions?

class MyExtensionNameSpecialPage extends SpecialPage { function getPageTitle( $subpage = false ) { return self::getTitleFor( $this->mName, $subpage ); } }

($mName is protected, so this is fine, but you can always use getName() instead.)