⚓ T245350 Drop support of MW <1.19

For older MediaWiki Pywikibot compat is more usable but it is no longer official maintained. It may be still an idea to (unofficially) port the compat to newer version of Python (though no new feature will be added).

Anyway per https://www.mediawiki.org/wiki/Manual:Pywikibot/Overview the core should theorically support MediaWiki 1.14, so it may be a real bug.

Please also note older install of MediaWiki may be highly customized (see http://www.wikitree.com/, it even disabled all special pages) so it is possible that neither core nor compat will work. Wikia already use a highly different editor.

For older MediaWiki Pywikibot compat is more usable but it is no longer official maintained. It may be still an idea to (unofficially) port the compat to newer version of Python (though no new feature will be added).

Pywikibot Compat is no longer officially maintained, yes. But as an unmaintained project, anyone can adopt it and do whatever they want to.

Anyway per https://www.mediawiki.org/wiki/Manual:Pywikibot/Overview the core should theorically support MediaWiki 1.14, so it may be a real bug.

This is what this task is about. Pywikibot tests don't test older MediaWiki wiki than 1.31.1, but Pywikibot docs still claim support for 1.14+. Pywikibot tests should definitely test lowest supported MediaWiki version (and perhaps even some other versions as well). We can establish test set of empty wikis (using WMCS?) or perhaps establish an empty wiki during tests (can increase testing time though). Also there are surely some issues with older MW version wikis (as noticed in the experiment described in the description), which should be solved on Pywikiobt's side or those MW versions should be dropped.

I instead think (only in my opinion) we should support we should continue to make it work in Fandom (1.19.24) for an unspecified time (probably drop it in 2025, 10 years after EOL of 1.19).

I agree because fandom is a most popular cluster. But their 1.19 release is also customised and has some deviations. We should be aware that we have only a couple of active developers and we spend a lot of time for actual problems with actual mw releases as well as Python versions already. Let's officially drop mw releases older than 1.19 with one of the next stable releases

I instead think (only in my opinion) we should support we should continue to make it work in Fandom (1.19.24) for an unspecified time (probably drop it in 2025, 10 years after EOL of 1.19).

I agree because fandom is a most popular cluster. But their 1.19 release is also customised and has some deviations. We should be aware that we have only a couple of active developers and we spend a lot of time for actual problems with actual mw releases as well as Python versions already. Let's officially drop mw releases older than 1.19 with one of the next stable releases

That's a good idea. I think we should support mainly clean 1.19 and do not much specify to Fandom specialties. On the other hand we could add one Fandom wiki to our tests as we used to with Wikia in the past.

On the other hand we could add one Fandom wiki to our tests as we used to with Wikia in the past.

wowwiki could be a candidate for it

Wikiapiary says that nearly 2/3 of all wikis use versions from obsolete branches but this analysis is not upto date because currently only MW 1.31, 1.33 and 1.34 hasn't reached its sunset. Currently we support 92 % of wikis up to mw1.14. With dropping 1.18 and below the supported wikis decrease to 64 %. The line of 50 % is with mw 1.21 and above. The most used mw version are 1.26 with 16 % and 1.16 with 10 %. LTS are mw 1.19, 1.23, 1.27, 1.31 and 1.35.

Supporting older mw versions has following aspects:

• We should support important mw versions if pywikibot is used there; the last aspect cannot be validated I guess. I think the supporting line should not decrease 50 % then.
• On the other hand supported mw versions must be tested. Can we find a test cluster for all of them? Does it increase CI tests a lot?
• Older mw may make it more difficult for further developing. We are only a few developers and we cannot do both: Keeping pace with ongoing development of current mw versions and support older mw. We cannot spend a lot of time for older versions with a handful people.
• Probably we can solve this problem above with a better versioning of our framework and a support matrix published somewere which shows the Python versions and MediaWiki versions supported. Maybe drop support of Python 2.7 and Python 3.4 and MediaWiki below 1.19 with next say 4.0 framework version. The next step can be dropping Python 3.5 and mw below 1.23 in 2021 with 5.0 Framework or sth like this.

Maybe drop support of Python 2.7 and Python 3.4 and MediaWiki below 1.19 with next say 4.0 framework version. The next step can be dropping Python 3.5 and mw below 1.23 in 2021 with 5.0 Framework or sth like this.

Seems reasonable, I support this

Seems reasonable, I support this

Should we start a new task to collect major changes pushed with next major pwb release?

Looking at Gerrit and pip/setuptools:

https://www.gerritcodereview.com/roadmap.html
https://setuptools.readthedocs.io/en/latest/history.html

What about this: PyPI description is so long currently. We could move history to a different place, but leave a link here. Then we could split current decomissions from HISTORY.rst into a separate file ROADMAP.rst (as HISTORY.rst is now even longer) and add these future release features into it. The structure would then be like this:

Roadmap
=======

Next release
------------

* End support of Python 2 and Python 3.4
* End support of MW < 1.19
* Move to SemVer
* Remove 10 years old desupports

Future releases
---------------

* **decomissions

History
=======

3.0.20200326
------------

* 
* 
*

Roadmap
=======

_include: ROADMAP.rst

History
=======

See <https://doc.wikimedia.og/pywikibot/master/history>

History
=======

_include: HISTORY.rst

or just

Roadmap
=======

_include: ROADMAP.rst

History
=======

See <https://gerrit.wikimedia.org/r/plugins/gitiles/pywikibot/core/+/refs/heads/master/HISTORY.rst>