As a workaround force_version could be used. Otherwise please … how do we want to handle that version? Is that 1.19.20 (so 1.19.21 is newer?) and discard the rest? I know that I've worked on changing this and afaik added that it's not allowing such weird versions but mostly because there is no sensible way in interpreting such a version number.

Okay in d6b6e4b3 I added that the complete version number must match a certain scheme. You commented there:

There are also 'official' distro releases with their own generator suffix, which we 'should' support, or at least track which cases currently fail, and have TODO's for any important cases which are not handled correctly.

https://wikiapiary.com/wiki/Generator:Generators/DEBIAN https://wikiapiary.com/wiki/Generator:Generators/CUSTOM

So it seems this is on of those cases. If there is a sensible scheme behind this we could add it but what if it's 1.19.20 with backported features from newer versions? There is no sensible match then (except for the lowest common denominator). Also the docstring of force_version specifically says that it can be used for that:

The site is usually using the version number from the servers'
siteinfo, but if there is a problem with that it's possible to return
a non-empty string here representing another version number.

(I just noticed it should be server's)

So for now I can only suggest to add the capability to return a callable which converts a incompatible version number in a compatible one (so that it's at least somewhat flexible).

We can know what each Debian version contains, and I think we should at least determine this for all the major distributions of MediaWiki so that they are properly supported.

wheezy : http://anonscm.debian.org/viewvc/pkg-mediawiki/mediawiki/branches/wheezy/debian/patches/
trunk/jessie: http://anonscm.debian.org/viewvc/pkg-mediawiki/mediawiki/trunk/debian/patches/

I dont see any patch which would cause the API to work differently from the released version for pywikibot. A few might make the server work correctly, where the released version doesnt work, however they are not cases where pywikibot does not currently try to workaround a bug in the server.

trunk has two extra patches
allow_pdf.patch
fix_variable_use.patch

Debian at least identifies itself. Fedora also packages MediaWiki, and it doesnt appear that it identifies itself, so we cant know whether its API has backports which cause it to operate differently.

However we should fallback on a sensible value, with a UserWarning to indicate that it isnt a fully supported or understood version. i.e. anything starting with 1.19.20 should be treated as 1.19.20 .

Three of the wikis on the IWM fail because of this:

https://wiki.gentoo.org/wiki/ : "1.24.2-gentoo"
http://wiki.arabeyes.org/ : "1.19.20+dfsg-2.3"
http://tfwiki.net/wiki/ : "1.19.5-1+deb7u1"

So https://wikiapiary.com/w/index.php?title=Concept:Generators_DEBIAN&action=edit uses

{{#concept:
 [[Category:Generator]]
 [[Has release type::DEBIAN]]
| This concept describes the [[Generator:Generators/DEBIAN|Generators]] released as a Debian package.
}}

Is there a bot detecting Debian and populating https://wikiapiary.com/wiki/Property:Has_release_type ? It would be good to share the algorithm .. ;-)

Change 234842 had a related patch set uploaded (by XZise):
[FIX] MediaWikiVersion: Support other versions

https://gerrit.wikimedia.org/r/234842

Change 234842 merged by jenkins-bot:
[FIX] MediaWikiVersion: Support other versions

https://gerrit.wikimedia.org/r/234842

(Note: if we can easily detect 'Debian', we could improve the algorithm.)