I was trying to parse the requirements for MW 1.41 and I want to make sure I got this straight.

A PHP version that is provided by a Debian Linux LTS release channel that will be supported for the duration of that MediaWiki release

Current Debian LTS is Buster, which shipped with PHP 7.3. That'll be EOL in June 2024. Next is Bullseye which shipped with PHP 7.4 and is presumably going to be supported until June 2026. Does this mean we'll have to keep PHP 7 around for 3 more years? And that when we will finally drop support for it, PHP 7.4. will have been fully EOL for 3+ years, PHP 8.2 will also be fully EOL, and the minimum actively supported version will be 8.4 (or 9.0, whatever comes after 8.3)? I don't think I'm reading this correctly. Especially because if this reasoning were correct, we would still be supporting PHP 7.3 until June 2024, but that's not the case since MW 1.39, and September 2022 for master (T278139, T261872). What did I get wrong?

Bullseye (released August 2021) was "a LTS version" of Debian upon the release of MW 1.39 in the same sense as Ubuntu LTS (released every two years), i.e. it has a long lifetime of security updates; it is just not usually called LTS until it moves into "LTS" support status.

A key point of such releases is that PHP etc. remain secure even though upstream may not be actively supporting them for ordinary users. Often they get assistance from the project with backporting security patches, and sometimes it is required as a condition of inclusion in the distribution's archive (this is why Matrix's Synapse server isn't in Debian releases anymore).

MediaWiki 1.39, that supports Bullseye as a Debian release, reaches EOL in November 2025. Wikimedia will need to keep PHP 7.4 around until then, which it can do because there's a Debian release supporting PHP 7.4.

In T328921#9138359, @Daimona wrote:

I was trying to parse the requirements for MW 1.41 and I want to make sure I got this straight.

A PHP version that is provided by a Debian Linux LTS release channel that will be supported for the duration of that MediaWiki release

Current Debian LTS is Buster, which shipped with PHP 7.3. That'll be EOL in June 2024. Next is Bullseye which shipped with PHP 7.4 and is presumably going to be supported until June 2026. Does this mean we'll have to keep PHP 7 around for 3 more years? And that when we will finally drop support for it, PHP 7.4. will have been fully EOL for 3+ years, PHP 8.2 will also be fully EOL, and the minimum actively supported version will be 8.4 (or 9.0, whatever comes after 8.3)? I don't think I'm reading this correctly. Especially because if this reasoning were correct, we would still be supporting PHP 7.3 until June 2024, but that's not the case since MW 1.39, and September 2022 for master (T278139, T261872). What did I get wrong?

Our job is not to support any hypothetical set-up; it's that people can use whichever MW release for the lifetime of that release on a single Linux/PHP platform without upstream going out of support, e.g. we shouldn't release an LTS version of MW that used PHP 7.3 today, as the version of Debian with 7.3 (Buster) goes EOL in June 2024 and our hypothetical version would go out of security updates in September 2024, so we'd leave our users exposed.

In practice, assuming our cadence and policy stay the same:

• the current LTS version of MW (1.39) shipped with PHP 7.4–8.1 support, later extended to 8.2, and will go EOL in November 2025 (bullseye supported; bookworm via backports)
• the current version (1.40) shipped with PHP 7.4–8.1 support, later extended to 8.2, and will go EOL in June 2024 (bullseye supported; bookworm via backports)
• the next version of MW (1.41) will ship in December 2023 with PHP 7.4–8.2 support, and will go EOL in December 2024 (bullseye and bookworm both supported);
• the one after that (1.42) will ship in June 2024, probably with 8.0–8.3 support, and will go EOL in June 2025 (bookworm supported)

So if we completely test all expected flavours of PHP in CI we'd need to keep 7.4 around until November 2025 (two more years), but in practice we might drop it earlier, once Wikimedia production rolls off 7.4, and rely on only minor changes being backported (and user reports) to keep 7.4 compatibility in policy but untested for 1.39/1.40. This is what we did with PHP 7.2 support testing.

Thank you, this summary is helpful because I had trouble parsing that policy as well 🙏

In T328921#9149629, @GreenReaper wrote:

Bullseye (released August 2021) was "a LTS version" of Debian upon the release of MW 1.39 in the same sense as Ubuntu LTS (released every two years), i.e. it has a long lifetime of security updates; it is just not usually called LTS until it moves into "LTS" support status.

Right, this has been confusing me a lot.

In T328921#9150067, @Michael wrote:

Thank you, this summary is helpful because I had trouble parsing that policy as well 🙏

Indeed, thanks for the summary! It would be really nice to have something like that in https://www.mediawiki.org/wiki/Support_policy_for_PHP

Based on the above, provisionally tagging against 1.42. We'll see.

I'm guessing this wants bumping to MW-1.43-release at this point, due to progress on T319432: Migrate WMF production from PHP 7.4 to PHP 8.1 et al.

Last change was rMWc0400d480d89: Drop PHP 7.2 & PHP 7.3 support in MediaWiki master; require 7.4.3 (which was in 1.40.0) from T261872: Drop PHP 7.2 & 7.3 support from MediaWiki master branch, once Wikimedia production is on 7.4.

I think it might be nicer for 1.42.0 to drop claims to PHP 7.4 support (even if we maintain it for Wikimedia use for the next few months), like we did for 1.40.

So more of a soft drop (ie composer.json/PHPVersionCheck), leaving master as is (for now, pending T319432)... Rather than allowing PHP 8.0/8.1 features throughout the codebase (ie because master is still PHP >= 7.4 for WMF production).

I feel like we've done this a couple of times, as you say.

I've just added 1.42 (initially, roughly) to https://www.mediawiki.org/wiki/Support_policy_for_PHP/Tables in relation to https://www.mediawiki.org/wiki/Support_policy_for_PHP to try and lay it out as things stand.

I believe that using PHP 8.1 is seemingly compatible, especially as 1.39 still supports PHP 7.4.

PHP 8.1 would be EOL by the time 1.42 is EOL...

In T328921#9620945, @Reedy wrote:

So more of a soft drop (ie composer.json/PHPVersionCheck), leaving master as is (for now, pending T319432)... Rather than allowing PHP 8.0/8.1 features throughout the codebase (ie because master is still PHP >= 7.4 for WMF production).

I feel like we've done this a couple of times, as you say.

Yes. We'd split this task into a sub-task for dropping from the 1.42 release branch, and this task would only be Resolve-able once production had moved.

I've just added 1.42 (initially, roughly) to https://www.mediawiki.org/wiki/Support_policy_for_PHP/Tables in relation to https://www.mediawiki.org/wiki/Support_policy_for_PHP to try and lay it out as things stand.

I believe that using PHP 8.1 is seemingly compatible, especially as 1.39 still supports PHP 7.4.

PHP 8.1 would be EOL by the time 1.42 is EOL...

Yeah, that seems reasonable too. Only issue is that Debian didn't ship 8.1, only 8.2 which we're still not fully testing. Happy to implement at 8.1 though?

In T328921#9620963, @Jdforrester-WMF wrote:

I've just added 1.42 (initially, roughly) to https://www.mediawiki.org/wiki/Support_policy_for_PHP/Tables in relation to https://www.mediawiki.org/wiki/Support_policy_for_PHP to try and lay it out as things stand.

I believe that using PHP 8.1 is seemingly compatible, especially as 1.39 still supports PHP 7.4.

PHP 8.1 would be EOL by the time 1.42 is EOL...

Yeah, that seems reasonable too. Only issue is that Debian didn't ship 8.1, only 8.2 which we're still not fully testing. Happy to implement at 8.1 though?

I think the criteria we have on https://www.mediawiki.org/wiki/Support_policy_for_PHP are fine..

A PHP version that is provided by a Debian Linux LTS release channel that will be supported for the duration of that MediaWiki release

We 'support' 8.2, even if it's not fully tested (bleugh).

I think as per usual, we'd happily accept PHP 8.2 bug reports against 1.42 (and earlier), and try and backport as appropriate. It doesn't seem there's any known show stoppers, maybe some logspam, due to some stuff outside our control too.

And as such, doing something about T356405: Add PHP 8.2 and PHP 8.3 to https://www.mediawiki.org/wiki/Compatibility#PHP once they're officially supported and any related tasks would be good.

From an external user perspective, it'd be nice to have a config flag to override that check, or a stiff warning rather than an outright error, though I can understand why not.

To me "not supported" is a long way from "actively breaks" - in this case, it's also "we can run it like this, but you can't".

Regarding versions, Ubuntu 22.04 LTS has 8.1 and I imagine many potential users are and will still be on it when considering MediaWiki 1.42 (and 1.43 for that matter). As the table shows, 20.04 also has 7.4 and is in standard support until April 2025.

Some people will be able to install other PHP versions, of course, and perhaps they should be encouraged to do so. I suspect there are environments where only distro PHP is allowed, though. (But then, maybe they would only allow LTS MediaWiki anyway?)

In T328921#9621148, @GreenReaper wrote:

From an external user perspective, it'd be nice to have a config flag to override that check, or a stiff warning rather than an outright error, though I can understand why not.

To me "not supported" is a long way from "actively breaks" - in this case, it's also "we can run it like this, but you can't".

No, this is "Over years and years, we've spent huge amounts of time hunting down issues that break sysadmin's systems only to eventually find that they are using an unsupported version of PHP and PHP's error is entirely impenetrable, so we've instead decided to make the error clear and up-front". It's not just a matter of choosing to block it; we also switch code over to use the new syntax/functions/features at the sane time.

Obviously you can hack your version of MW however you want, including patching PHPVersionChecker and just hoping you don't trigger unfortunate code paths, but it's entirely unsupported and definitely not something we'll imply we support by adding a flag to trigger it.

Regarding versions, Ubuntu 22.04 LTS has 8.1 and I imagine many potential users are and will still be on it when considering MediaWiki 1.42 (and 1.43 for that matter). As the table shows, 20.04 also has 7.4 and is in standard support until April 2025.

Some people will be able to install other PHP versions, of course, and perhaps they should be encouraged to do so. I suspect there are environments where only distro PHP is allowed, though. (But then, maybe they would only allow LTS MediaWiki anyway?)

Fair enough. I appreciate how frustrating such reports can be, and even if core unofficially works on 7.x for a time, extensions may not. Conversely, it seems most extension compatibility issues are fixed now, for 8.1 at least.

To help those without direct support for PHP 8.1 on their OS (including Arch, which now seems to offer only 8.3/8.2), I've added a list of what seem to be the best-supported community package options to the Compatibility page.