Why upgrade?
When we imported the Wikimini's wiki farm into the WMCH-Infrastructure we kept their legacy MediaWiki version, 1.28.0, in order to concentrate on migration issues and avoid to introduce additional regressions.
This had some security implications that cannot be disclosed here, anyway, we have the responsibility to plan an upgrade ASAP to at least MediaWiki 1.31. That version is the current stable version provided by Debian GNU/Linux buster 10 (current stable). We also have the possibility to update to MediaWiki 1.35 proposed by the buster-backports package.
I generally would be inclined in updating directly from 1.28 to 1.35 for the simple fact that updating MediaWiki usually works as expected nowadays and and that nowadays intermediate advances are not recommended (because in recent versions you have the benefit of fix for old broken updates). Moreover I have a lot of faith in the maintainer of the backports package. Anyway, we can pull the rollback lever in case of troubles.
Some benefits for MediaWiki 1.31:
- significantly improve security (adopting a clean verified core)
- improve user experience of multimedia files
- simplify ordinary maintenance (thanks to the package manager, and getting rid by the legacy VisualEditor Parsoid/JS service)
- simplify security maintenance (provided by the package maintainer)
- improve patrolling with block IP-ranges
- improve cache systems ($wgUseFileCache)
Additional benefits for MediaWiki 1.35:
- improve user experience adopting newer versions of VisualEditor
- improve user experience with Scribunto and Lua modules to build advanced templates
- improve patrolling with partial blocks
See also this page we've contributed to:
For historical reasons here the Wikimini's version matrix at November, 27 2020 (before this upgrade):
http://web.archive.org/web/20201127095550/https://fr.wikimini.org/wiki/Sp%C3%A9cial:Version
Upgrade Plan
Here we can work on an upgrade plan.
Hours are expressed as working-hours, considering a certain margin of unexpected last-minute mess on common sense - I mean, not a fire disaster in the datacenter.
- understand the fate of the https://es.wikimini.org/ spam-filled beta edition (drop or clean)
- 0 h drop
- 8 h clean
-
4 hdeploy a separated test environment of the wiki farm (T277880)- databases
- fr
- stock
- filesystem files
- databases
- 4 h disable all the extensions and try a clean database upgrade in the testing environment for each edition
- T331153: Wikimini extensions review
- 6 h try to update each needed extension
- 4 h re-import again the production databases in testing and re-try a full one-step upgrade
- plan and announce a read-only window
- 8 h final production upgrade
- activate maintenance mode in production
- backup production again (database and files)
- overwrite production's core
- overwrite production's extensions
- upgrade each edition
- test
- something really weird happened (e.g. the datacenter is completely on fire)
- eventually rollback everything
- disable maintenance mode
- last minute fixes
- Champagne!