Page MenuHomePhabricator

Upgrader should check extensions against current version
Open, NormalPublic

Description

From http://thread.gmane.org/gmane.org.wikimedia.mediawiki/40587

A suggestion: How feasible would it be for the upgrader to (a) detect
extensions in use (b) check their mediawiki.org page re:
upgradeability [template-scraping] and give their status?

This should definitely be done.


Version: 1.21.x
Severity: enhancement

Details

Reference
bz42393

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 22 2014, 12:54 AM
bzimport added a project: MediaWiki-Installer.
bzimport set Reference to bz42393.
bzimport added a subscriber: Unknown Object (MLST).

I was thinking in terms of scraping the infobox - an extension's infobox template on mediawiki.org constitutes well-curated metadata.

(The next question is how fixed is the presence of that template on extension pages, and the format of the template.)

The question came up when I upgraded a work wiki from 1.17 to 1.19.2 - it had lots of extensions, including:

(a) upgraded in the MediaWiki tarball;
(b) a newer version existing for 1.19;
(c) no newer version existing for 1.19, current is fine;
(d) extension has changed name (ArrayExtension changing to Arrays), upgrade.

There would also be (e) extension doesn't work with this version, you may have to remove it.

I'm not sure how to flag updatability. My use case was SyntaxHighlight-GeSHi, which didn't change at all between versions for 1.17 and 1.19, as I discovered when I downloaded the tarball for 1.19.

Of course, if an extension doesn't say it lives on mediawiki.org, direct the upgrader to its listed page.

Currently we're not even getting extension matrix updates https://www.mediawiki.org/wiki/User_talk:Alterego#Last_releases
Making the infoboxes up to date is a giant task...

(Adding Antoine and Chris so we can get their input.)

(In reply to comment #2)

Making the infoboxes up to date is a giant task...

Agreed. Perhaps we could say that if you provide tests for your extension, we can it against the release using Jenkins.

If we can automate testing in this way, then we'll be able to say "Extension version X is supported in MW version Y". right?

If that is possible, then it seems like a way to bootstrap testing of extensions, as well.

Speaking as someone using lots of extensions, and treating the extensions' mediawiki.org pages as reliable information on the state of said extensions, that's more than a little disconcerting.

Sounds like the thing to do is to set up the incentives to get extension authors to keep their extension's infobox up to date. Perhaps that's a separate bug ...

Is there a middle ground? Somewhere so that we could use MW.o infoboxes *OR* jenkins testing depending on the extension? Or, we could update infoboxes from the jenkins tests...

(In reply to comment #4)

Sounds like the thing to do is to set up the incentives to get extension
authors to keep their extension's infobox up to date. Perhaps that's a separate
bug ...

Yes, it's surely beyond the scope of this bug.

As for the general problem:

For the purposes of this bug, "no information on compatibility of this extension with your new MediaWiki" counts as useful information.

fbstj added a subscriber: fbstj.Dec 30 2014, 6:51 PM
Paladox set Security to None.Jul 6 2015, 12:09 AM
Paladox added a subscriber: Aklapper.
fbstj awarded a token.Dec 15 2015, 2:55 PM
fbstj removed a subscriber: fbstj.