8.1 not 8.0 or 8.2?

Making CI passing wmf-deployed MediaWiki extensions on PHP 8.0 and PHP 8.1.

The wmf-quibble jobs are rather expensive. Do we really need to run these for 8.0 as well as 8.1 if we're not going planning to deploy to that target ever?

In T319432#8315497, @Jdforrester-WMF wrote:

The wmf-quibble jobs are rather expensive. Do we really need to run these for 8.0 as well as 8.1 if we're not going planning to deploy to that target ever?

The wmf-quibble jobs should use whatever PHP versions are currently in use at Wikimedia so indeed that would be 8.1.

That being said, we should still test them with 8.0, but with the regular quibble jobs rather than the wmf-quibble integration one.

In T319432#8315497, @Jdforrester-WMF wrote:

8.1 not 8.0 or 8.2?

The next target for production is PHP 8.1. In practical terms, this was decided by perf and SRE as the ones proposing and pushing for the objective and resourcing it as-needed. (I recognise of course that yourself and @Reedy have already been doing a lot of work in addressing deprecation warnings as part of making MediaWiki master pass CI, for releases and local dev on PHP 8.x, and thus in prep for production PHP 8.x).

We choose PHP 8.1, based on PHP 8.2 not being ready yet, and possibly too big a jump from PHP 7.4 in one go to ease vendor management. We can skip PHP 8.0 and doing so reduces the number of migrations we have to carry out. If there are benefits to individual teams and maintainers if we stop at PHP 8.0 first, though, this is certainly something we can consider. I'm not aware of a major reason against PHP 8.0 in prod. But let us know soon in that case so that we can adjust plans, or alternatively by helping resolve the issue another way.

In T319432#8338918, @Krinkle wrote:

In T319432#8315497, @Jdforrester-WMF wrote:

8.1 not 8.0 or 8.2?

The next target for production is PHP 8.1. In practical terms, this was decided by perf and SRE as the ones proposing and pushing for the objective and resourcing it as-needed. (I recognise of course that yourself and @Reedy have already been doing a lot of work in addressing deprecation warnings as part of making MediaWiki master pass CI, for releases and local dev on PHP 8.x, and thus in prep for production PHP 8.x).

We choose PH 8.1 based on PHP 8.2 not being ready yet, and possibly too big a jump from PHP 7.4 in one go to ease vendor management. We can skip PHP 8.0 and doing so reduces the number of migrations we have to carry out. If there are benefits to individual teams and maintainers if we stop at PHP 8.0 first, though, this is certainly something we can consider. I'm not aware of a major reason against PHP 8.0 in prod. But let us know soon in that case so that we can adjust plans, or alternatively by helping resolve the issue another way.

Happy the decision has been made; no particular pressure for 8.0 from me! Could the decision, who made it, and what went into it be documented somewhere (and ideally announced)? Thanks!

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

[mediawiki/core@master] MediaWiki-Docker: Switch PHP images to PHP 8.1

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

Commit 9e7b5c19... pushed by jforrester:

[ repos/releng/dev-images @php81] Add PHP 8.1 images

Commit 9e7b5c19... pushed by brennen:

[ repos/releng/dev-images @main] Add PHP 8.1 images

brennen merged https://gitlab.wikimedia.org/repos/releng/dev-images/-/merge_requests/23

Add PHP 8.1 images

Mentioned in SAL (#wikimedia-releng) [2022-12-07T22:59:44Z] <brennen> Updating development images on contint primary to release php 8.1 images for T319432

Change 855580 merged by jenkins-bot:

[mediawiki/core@master] MediaWiki-Docker: Switch PHP images to PHP 8.1

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

Thanks for this task.

Just to put this in writing, serviceops has planned to do the Per Cluster ramp-up in the April-Jun quarter (this quarter we are focusing on MediaWiki on Kubernetes, which should contribute to making future PHP migrations easier). The prep work (e.g. CI, some ICU work needed by SRE) can happen well before that of course.

In T319432#8338918, @Krinkle wrote:

We choose PHP 8.1, based on PHP 8.2 not being ready yet

In the meantime, 8.2 has been out for over nine months, and it’s the version included in Debian Bookworm. Are you sure it makes sense to stick with 8.1, despite it not being included in any Debian version? It would be important to support at least one PHP version Debian includes (i.e. 7.4 or 8.2) for the benefit of third-party wikis; while it doesn’t need to be the one used in WMF production, it’s easier to support a PHP version if we ourselves use it.

Configure MW with ICU emulation for PHP 8.1 that matches PHP 7.4 (see also: T263437: Allow easier ICU transitions in MediaWiki (change how sortkey collation is managed in the categorylinks table), T292552: Rename articles and users to update our case mapping to PHP 7.4 and Unicode 11).

I'm not sure where to raise this, so I'll raise it here: the category collation transition should also be done for 'uppercase' collations, not just ICU collations, as they are also affected by upgrades. For example, see T323868 and T251698 where this problem was reported.

In T319432#9177477, @Tacsipacsi wrote:

In T319432#8338918, @Krinkle wrote:

We choose PHP 8.1, based on PHP 8.2 not being ready yet

In the meantime, 8.2 has been out for over nine months, and it’s the version included in Debian Bookworm. Are you sure it makes sense to stick with 8.1, despite it not being included in any Debian version? It would be important to support at least one PHP version Debian includes (i.e. 7.4 or 8.2) for the benefit of third-party wikis; while it doesn’t need to be the one used in WMF production, it’s easier to support a PHP version if we ourselves use it.

https://www.mediawiki.org/wiki/Support_policy_for_PHP