Change 826216 had a related patch set uploaded (by Jforrester; author: Jforrester):

[integration/config@master] Zuul: [mediawiki/core] Make PHP 8.1 voting on REL1_38 and REL1_39

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

Change 826216 merged by jenkins-bot:

[integration/config@master] Zuul: [mediawiki/core] Make PHP 8.1 voting on REL1_38 and REL1_39

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

Mentioned in SAL (#wikimedia-releng) [2022-08-29T11:28:30Z] <James_F> Zuul: [mediawiki/core] Make PHP 8.1 voting on REL1_38 and REL1_39 for T316080

Change 831644 had a related patch set uploaded (by Hashar; author: Brian Wolff):

[integration/config@master] Remove php8.1 as voting for REL1_39. Doesn't pass currently.

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

Change 831644 abandoned by Brian Wolff:

[integration/config@master] Remove php8.1 as voting for REL1_39. Doesn't pass currently.

Reason:

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

1.35 has some voting PHP 8.1 tests...

https://integration.wikimedia.org/ci/job/mediawiki-quibble-composertest-php81-docker/111/console : SUCCESS in 1m 13s

and some non voting (experimental)

https://integration.wikimedia.org/ci/job/mediawiki-quibble-composer-mysql-php81-docker/379/console : FAILURE in 1m 16s

PHP Deprecated:  Return type of RemexHtml\Tokenizer\PlainAttributes::offsetExists($key) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /workspace/src/vendor/wikimedia/remex-html/RemexHtml/Tokenizer/PlainAttributes.php on line 24

That would need https://gerrit.wikimedia.org/r/c/mediawiki/libs/RemexHtml/+/786306, tagged with 3.0.2 and 3.0.3, REL1_35 is using 2.2.0 - not sure if that is possible to upgrade

Fatal error: During inheritance of ArrayAccess: Uncaught Return type of Pimple\Container::offsetExists($id) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice

That would need https://github.com/silexphp/Pimple/commit/7a4a44b13fa74d4effbaa3d93e63624c95fd4418, tagged with 3.5.0, REL1_35 is using 3.3.1 - not sure if that is possible to upgrade

Deprecated: Wikimedia\Rdbms\MySQLMasterPos implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /workspace/src/includes/libs/rdbms/database/position/MySQLMasterPos.php on line 19

The fix is in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/758800, which is backported. But the rename from MySQLMasterPos to MySQLPrimaryPos was missed, and the "new" class MySQLPrimaryPos was dropped completly (in REL1_36 patch) and not merged into the old name

Deprecated: Return type of Wikimedia\Rdbms\FakeResultWrapper::valid() should either be compatible with Iterator::valid(): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /workspace/src/includes/libs/rdbms/database/resultwrapper/FakeResultWrapper.php on line 82

Deprecated: Return type of Wikimedia\Rdbms\FakeResultWrapper::rewind() should either be compatible with Iterator::rewind(): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /workspace/src/includes/libs/rdbms/database/resultwrapper/FakeResultWrapper.php on line 61

With https://gerrit.wikimedia.org/r/c/mediawiki/core/+/704743 the class was refactored and there exists no backport for that specific case. Backporting the big refactoring is a risk.
Need a own patch with the changes from ResultWrapper in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/786303/6/includes/libs/rdbms/database/resultwrapper/ResultWrapper.php

That would bring the "PHPUnit default suite (without database or standalone)" step further (it seems not finished it run, fataled by 3%).
After that there is another run for the Database group, which can have also failures.
The failures from T274965 should be seen here as well

This is what I was meaning about diminishing returns (on another task) of getting newer PHP support on 1.35. Especially as 1.39 is now released.

https://github.com/silexphp/Pimple/compare/v3.3.1...v3.5.0 would look pretty trivial, especially as a require-dev dependancy

pimple update is not easy, it includes psr/container 1.1.0, that requires object-factory 3.0.1 (and psr/container 1.1.1) and that parsoid 0.13.0

When testing further (with the supported remex version, which includes namespace change in code) we need https://github.com/guzzle/guzzle/commit/b22ead0a39ca708da0bfdbb3e83bc652f7a03f2a from guzzlehttp/guzzle 7.2.0, REL1_35 ist at 6.5.8

At next to include https://gerrit.wikimedia.org/r/c/mediawiki/libs/CommonPasswords/+/788852

Seeing some "strtr(): Passing null to parameter #1 ($string) of type string is deprecated" in the failures

The effort to support php8.1 in REL1_35 is to high from my point of view due to the return type things and null errors from internal functions and many libs require version bumps for that.
Even all the php8.1 are not fixed in master of extensions.

Who can decide to decline php8.1 support for REL1_35 and change the documentation?

In T316080#8507296, @Umherirrender wrote:

Who can decide to decline php8.1 support for REL1_35 and change the documention?

Which documentation in particular? I'm happy to decline whatever tasks (myself or James F have probably authored most of them), including this one. Though it's also partially fixed, so maybe not a straight decline.

Our wording has been... not great (unofficially, you might call it "best effort"). Might be a good time to have a bigger think on it.

Thanks for the effort in trying to make it work though.

https://www.mediawiki.org/wiki/Support_policy_for_PHP was written from T228342: Define criteria for setting explicit PHP support target for MediaWiki.

And of course, the graph on https://www.mediawiki.org/wiki/Compatibility#PHP doesn't agree :)

In T316080#8507340, @Reedy wrote:

https://www.mediawiki.org/wiki/Support_policy_for_PHP was written from T228342: Define criteria for setting explicit PHP support target for MediaWiki.

I feel trying to turn https://www.mediawiki.org/wiki/Support_policy_for_PHP#Criteria into a table (possibly on a different page, and one created for each release, at least of writing, currently supported) would make it helpful, rather than a lot of vaguities...

https://www.mediawiki.org/wiki/Support_policy_for_PHP/Tables - I'd like to try and integrate that into somewhere, and keep it up to date going forward (at least listing currently supported MW versions).

Using text from https://www.mediawiki.org/wiki/Support_policy_for_PHP#Criteria

A PHP version that will be supported by the upstream PHP Group for the full duration of that MediaWiki major release cycle (from our planned release date until our planned end-of-life date).

So for 1.35... As PHP 8.0 is supported till 2023-11-26, we're good on that front (I think? 1.35 is mostly good on PHP 8.0?).

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

Debian 11 "Bullseye" meets that criteria, providing PHP 7.4

A PHP version that is provided by an Ubuntu Linux LTS release channel that will be supported for the duration of that MediaWiki release.

Ubuntu 20.04 "Focal" meets that criteria, providing PHP 7.4

For every Debian Linux LTS and Ubuntu Linux LTS release there must be at least one compatible MediaWiki version that is supported at the time the Linux distribution's LTS period starts.

Noting "at the time the Linux distribution's LTS period starts"... And doing this based on "now" for ease.

Debian 11 is supported by MW 1.35, 1.38 and 1.39

18.04 would've been supported by MW 1.31..

20.04 is supported by MW 1.35, 1.38 and 1.39

22.04 is supported (ish/we're still working on/backporting PHP 8.1 stuff) by MW 1.38 and 1.39

At any given point in time, there must be at least one combination of Debian Linux LTS and MediaWiki that both parties support for an overlapping period of two years. Thus allowing a site operator to remain on a given combination for 2 years (with support), before upgrading to the next supported combination. The same applies to Ubuntu Linux LTS as well.

I think 1.35 and 1.39 with Debian 11 roughly covers it.

I'm not going to claim we're covering every single edge case here, but I think there's a reasonable coverage.

To that extent, I think we're good to claim that PHP 8.1 support for 1.35 was aspirational, but is being declined due to other supported options (OS versions, released MW versions, including a newer LTS in 1.39) and technical complexity?

See also https://www.mediawiki.org/wiki/Topic:Vq314o4gshbvivre and https://docs.google.com/spreadsheets/d/1XGLa9czz1fu1pNWreuUMKezAOkoZqSgQOSx7nB1l7X8/edit#gid=0 for some other data

In T316080#8507414, @Reedy wrote:

To that extent, I think we're good to claim that PHP 8.1 support for 1.35 was aspirational, but is being declined due to other supported options (OS versions, released MW versions, including a newer LTS in 1.39) and technical complexity?

Finishing off T274966: Make MW 1.35 tests pass on PHP 8.0 would be good, even if MW 1.35 "mostly works" on PHP 8.0 anyway...

Thanks for the look into the compatibility, that looks very comprehensible to me.