Page MenuHomePhabricator

Define criteria for setting explicit PHP support target for MediaWiki
Open, Needs TriagePublic0 Story Points

Description

Problem statement

We don't have a predictable timeline for when or how often we change the required PHP version of MediaWiki. It is also unclear how we will determine what the required PHP version will be.

The conversation of starting to drop a version evolves organically and ad-hoc, at which point a task, usually involving TechCom. If we forget to during a year, or if the task takes too long to reach consensus, we may forget to bump the requirement in time which then results in long-term cost for maintenance, support, testing etc.

Objective
  • To document which criteria MediaWiki releases will use to decide the PHP versions it supports.
  • To not have an RFC every time we want to raise the PHP version requirement.
  • To evaluate these criteria on a regular basis, and when needed, raise the requirement accordingly.
Proposal 1

Based on @Krinkle's comment at T216165#5284682.

I'd like to propose a set of wishes we would use to determine the PHP versions we want and need to support (and not support versions older than those).

  • We prefer not to support a PHP version beyond its EOL. (This means each MW x.0 stable release will only support PHP versions that don't go EOL before the MW release goes EOL; unless required for another bullet point.)
  • We prefer not to support an Ubuntu or Debian version beyond its EOL. (This means each MW x.0 stable release will only support Debian+Ubuntu versions and their PHP versions if they don't go EOL before the MW release goes EOL; unless required for another bullet point.)
  • Each Ubuntu and Debian version must have at least one MW version that we still support when the Linux release cycle starts.
  • Administrators using the Ubuntu and Debian LTSes must have a clear upgrade path from one combination of Linux/PHP/MW to the next without any gaps where they aren't supported, and to be able to remain on such a combination for 2 years.
Proposal 1 (Example for current state)

PHP

  • PHP 7.1 support: Dec 2016 - Dec 2019
  • PHP 7.2 support: Nov 2017 - Nov 2020
  • PHP 7.3 support: Dec 2018 - Dec 2021

Ubuntu:

  • Ubuntu 18.04 LTS: mid-2018 - mid-2023 (PHP 7.2)
  • Ubuntu 20.04 LTS: mid-2020 - mid-2025 (PHP 7.3, maybe later)

Debian:

  • Debian 9 Stretch: mid-2017 - 2022 (PHP 7.0)
  • Debian 10 Buster: mid-2019 - 2022+ (PHP 7.3)

MediaWiki

  • MediaWiki 1.31: June 2018 - June 2021 (PHP 7.0+)
  • MediaWiki 1.32: Jan 2019 - Jan 2020 (PHP 7.0+)
  • MediaWiki 1.33: June 2019 - June 2020 (PHP …)
  • MediaWiki 1.34: November 2019 - November 2020 (PHP …)
  • MediaWiki 1.35 LTS: June 2020 - June 2023 (PHP …)

Let's see which versions we would need to require for MW 1.34+ whilst upholding the proposed criteria.

The only Linux combination we need to look at is Debian 9 Stretch with PHP 7.0. On that platform, we support MW 1.31 from June 2018 to June 2021 within the Debian 9 cycle, which gives them 3 years (we require 2).

By June 2021, there will be Debian 10 and several MediaWiki releases that support for PHP 7.2, which gives them a clear upgrade path without any gaps where they aren't supported.

This means for MW 1.34 we would drop PHP 7.0, and 7.1, and require PHP 7.2+.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 17 2019, 9:05 PM
MaxSem added a subscriber: MaxSem.Jul 24 2019, 8:06 AM

This sounds good to me.

Krinkle updated the task description. (Show Details)Jul 28 2019, 3:32 PM
cscott added a subscriber: cscott.EditedJul 31 2019, 9:25 PM

This is consistent with merging Parsoid into core as a library (not an extension), as Parsoid/PHP is current PHP 7.2+. So we could start integrating it in MW 1.33/1.34 if we require PHP 7.2+.

Otherwise Parsoid would spend some time as an extension, or we'd backport and remove PHP 7.2 features, or... we've got options. So this isn't a strong requirement, but it would save us some work if the PHP 7.2 transition lined up with the Parsoid/PHP transition.

(We chose PHP 7.2 for the port because the stronger typechecking is helping us find porting bugs. The idea was that we could later strip the type checks if it was really necessary in order to integrate with core, but not until Parsoid/PHP reaches parity with JS and has Zarro Boogs (T44467).)

1.33 has already been released - did you mean 1.34?

One additional requirement/criteria I'd like to add:

  • We only bump PHP version at the time of releasing a new LTS. This means that people aren't constantly having to update PHP every 6 months, plus the CI team doesn't constantly have to be reacting to these bumps (also codesniffer and other tooling changes). Backporting security patches doesn't have to constantly figure out which syntax is OK or not (or at least, it keeps it at the current volume).

One additional requirement/criteria I'd like to add:

  • We only bump PHP version at the time of releasing a new LTS. This means that people aren't constantly having to update PHP every 6 months, plus the CI team doesn't constantly have to be reacting to these bumps (also codesniffer and other tooling changes). Backporting security patches doesn't have to constantly figure out which syntax is OK or not (or at least, it keeps it at the current volume).

I'd discourage this line of thinking, a little. Changing versions only at LTS releases means

  • (a) much increased testing stress for the LTS release — risking the timing and confidence of the release and increasing the likelihood that we need to do an emergency follow-up point release — which undermines the confidence sysadmins would have in such a release,
  • (b) many extensions will not be rigorously tested on the new PHP target platform before release, meaning that the nominally LTS-compatible branches are likely to "ship" with bugs, incompatibilities, and issues (as many of our ecosystem's developers work on improvements to extensions they maintain to scratch their own itch), as well as
  • (c) slowing down adoption of improved tools/etc.

If slowing down development is your intent (which I think is a bad idea, but hey), we could instead say "release before an LTS" as the target for migrations.

How does this relate to dropping HHVM support? Is it useful to require PHP 7.2 but also support HHVM? Should T192166 block this, and does it have a timeline?

How does this relate to dropping HHVM support?

It doesn't, that RfC has already concluded.

Is it useful to require PHP 7.2 but also support HHVM?

Not really, but it's not terminal.

Should T192166 block this, and does it have a timeline?

No.

If it's not really useful to require 7.2 before dropping HHVM support, is it worth making third-party admins upgrade their PHP? I don't know how many there are who will need to, but it's presumably nonzero, so shouldn't we identify some clear benefit to us before inconveniencing them?

If it's not really useful to require 7.2 before dropping HHVM support, is it worth making third-party admins upgrade their PHP?

Sorry, "not really" as in "not really related". Anyone trying to run MediaWiki in HHVM is already on a losing streak when it comes to technology changes, but they are entirely unaffected by this change.

I don't know how many there are who will need to, but it's presumably nonzero, so shouldn't we identify some clear benefit to us before inconveniencing them?

From your comment it appears that this isn't clear to you already in the text above? What in Krinkle's text would you like to see expanded to make this point?

I don't see anywhere in Krinkle's text that explains the benefits of dropping support for older PHP versions. I assumed it was so we'd be able to use features of newer PHP versions in core code (because that's why I want to require a newer version :) ). If this is the case, I'm interested in knowing what new features we could use while still supporting HHVM. If there's some other reason entirely that we want to require a higher version, that explains my confusion.

Why use a newer version? Here are a few of my insights:

  • Developers can use the latest syntax to achieve a better system architecture
  • Older versions are not supported and have security risks.
  • The new version usually means an improvement in performance, and PHP 5 to 7 is an example.
  • Only supporting fewer versions means that developers can only focus on compatibility between a small number of versions.

[..] Here are a few of my insights: [..]

These are all good reasons, however in my opinion (aside from the last one) none of these are strong enough reasons to drop support for.

  • Newer syntax isn't particularly important to me.
  • Security risks only affect users of those older versions. I don't think "dropping support" should be our primary way of motivating third parties to upgrade their PHP packages.
  • Same for performance; allowing users to upgrade for better performance doesn't require dropping older versions.

I don't see anywhere in Krinkle's text that explains the benefits of dropping support for older PHP versions. I assumed it was so we'd be able to use features of newer PHP versions in core code [..]

The opening statement contains my own reasons. They push both toward and way from older versions. Together they aim for a balance with which we get the maximum compatibility range, with the lowest maintenance cost:

  • [cost, drop] We prefer not to support a PHP version beyond its EOL.
  • [cost, drop] We prefer not to support an Ubuntu or Debian version beyond its EOL.
  • [benefit, support] Each Ubuntu and Debian version must have at least one MW version that we still support when the Linux release cycle starts.
  • [benefit, support] Administrators using the Ubuntu and Debian LTSes must have a clear upgrade path from one combination of Linux/PHP/MW to the next without any gaps where they aren't supported, and to be able to remain on a combination for at least 1 year, preferably 2.

[..] I'm interested in knowing what new features we could use while still supporting HHVM. If there's some other reason entirely that we want to require a higher version, that explains my confusion.

I'm not aware of any PHP 7.2+ only features that are supported by HHVM, and that we're excited about using soon in MW. There is various stuff about return types new in PHP 7.0 (and supported in HHVM), that we've already begun using.

We only keep HHVM compat for WMF purposes whilst WMF migrates away. Once done, we might even consider dropping compat immediately and retroactively from all current and past branches. In any event, this task is about our support policy for Zend PHP. Our HHVM support is orthogonal.

Remember that this task is not about what we do for the next MediaWiki release. This task is about our support policy in general, including for MW releases made after HHVM is out of the picture (at which point it no longer restricts feature usage).

The idea being, then, that we just don't want to waste resources fixing 7.0-specific problems when it's already been EOL'd? That makes perfect sense, I just got confused because of my own assumptions about why we'd want to drop support for old PHP. (There are plenty of 7.1/7.2 features I'd love to use!)

It's worth pointing out that as long as 7.0 is still likely to work in practice, even if we don't officially support it, it might be nice to sysadmins to not force it to fail -- i.e., not increasing minSupported in PHPVersionCheck. It might be more appropriate to print warnings that the PHP version isn't supported but still let the wiki try to work. Usually when we require a new version, we start using features that will definitely cause everything to break anyway in old versions, so it's better to display an informative error message right away instead.

Whether any of this is worth anyone's effort is another question. I apologize for disturbing everyone. :)

daniel moved this task from Under discussion to Inbox on the TechCom-RFC board.Aug 21 2019, 5:41 PM

Requesting Last Call per James on IRC:

<James_F> duesen: And a Final Call on the RfC would be smashing, if you can swing it. ;-)(

Moving to TechCom's inbox for review at the next meeting.

RhinosF1 added a subscriber: RhinosF1.
This comment was removed by RhinosF1.

looked at the wrong task :)

brion renamed this task from Set explicit PHP support target for MediaWiki to Set explicit PHP 7.2 support target for MediaWiki.Wed, Aug 28, 8:32 PM
brion updated the task description. (Show Details)
brion updated the task description. (Show Details)
brion renamed this task from Set explicit PHP 7.2 support target for MediaWiki to Define criteria for setting setting explicit PHP support target for MediaWiki.Wed, Aug 28, 8:36 PM
brion updated the task description. (Show Details)

I'd discourage this line of thinking, a little. Changing versions only at LTS releases means

  • (a) much increased testing stress for the LTS release — risking the timing and confidence of the release and increasing the likelihood that we need to do an emergency follow-up point release — which undermines the confidence sysadmins would have in such a release,

I don't think that would be the case. Why would you need to test the dropping of support for a PHP version? I can imagine there being emergency follow-up releases for adding support for PHP versions, but not for dropping them.

  • (b) many extensions will not be rigorously tested on the new PHP target platform before release, meaning that the nominally LTS-compatible branches are likely to "ship" with bugs, incompatibilities, and issues (as many of our ecosystem's developers work on improvements to extensions they maintain to scratch their own itch), as well as

This again applies only to adding PHP versions.

PHP 7.3 is the current stable release of PHP and should already be fully supported by MediaWiki. We are not waiting until 7.2 goes EOL before beginning to support 7.3.

Krinkle updated the task description. (Show Details)Wed, Aug 28, 9:12 PM
Krinkle added a comment.EditedWed, Aug 28, 9:15 PM

TechCom is placing this on Last Call for two weeks, ending Wed 11 Sept 2019 at 15:00 UTC (08:00 PST, 17:00 CEST).

Krinkle moved this task from Inbox to Last Call on the TechCom-RFC board.Wed, Aug 28, 9:15 PM

I'd discourage this line of thinking, a little. Changing versions only at LTS releases means

  • (a) much increased testing stress for the LTS release — risking the timing and confidence of the release and increasing the likelihood that we need to do an emergency follow-up point release — which undermines the confidence sysadmins would have in such a release,

I don't think that would be the case. Why would you need to test the dropping of support for a PHP version? I can imagine there being emergency follow-up releases for adding support for PHP versions, but not for dropping them.

I think we had to do this for the 7.0 switch, didn't we? My concern is around emergency follow-ups for breakage in removing old code paths that weren't quite as old as documented, mostly found by third parties due to different config using different code branches.

  • (b) many extensions will not be rigorously tested on the new PHP target platform before release, meaning that the nominally LTS-compatible branches are likely to "ship" with bugs, incompatibilities, and issues (as many of our ecosystem's developers work on improvements to extensions they maintain to scratch their own itch), as well as

This again applies only to adding PHP versions.
PHP 7.3 is the current stable release of PHP and should already be fully supported by MediaWiki. We are not waiting until 7.2 goes EOL before beginning to support 7.3.

Automated testing, yes, but not manual testing, and the former misses out a huge amount of work.

Code running on Wikimedia wikis is almost always only reasonably tested on the platform(s) we use (and even then, many code paths aren't due to config variations).

There's a reason we're very careful and gradual to upgrade the version of PHP in Wikimedia production, and I think we should try to take roughly directional if somewhat lower levels of care about claims for compatibility for third-party releases.

That's another thing, the task description lacks any mention of WMF production, which has often been the sole reason for continuing to support a given PHP version.

I'm sympathetic to @Legoktm's request that we avoid complicating CI and backports by regularly changing the supported PHP version. At most we can change our minimum supported PHP version once for every major PHP release, but in the past we have not updated it as often as that. PHP releases are approximately annually, so at most we could update the minimum PHP version once every two major MW releases. This ticket proposes PHP 7.2 for MW 1.34, when it was last updated from PHP 7.0 for MW 1.31, so a gap of three major MW releases. I think that's a reasonable compromise, and a minimum update period of 18 months and 3 major MW releases seems like a reasonable policy going forwards.

Dinoguy1000 renamed this task from Define criteria for setting setting explicit PHP support target for MediaWiki to Define criteria for setting explicit PHP support target for MediaWiki.Thu, Aug 29, 6:27 AM

Note that we've done minor version bumps e.g. from 7.0.0 to 7.0.13 for T209423 due to PHP bug https://bugs.php.net/bug.php?id=66862; would those kind of minor version changes be in scope for your 18 month guideline?

Izno added a subscriber: Izno.Sun, Sep 1, 3:30 PM
Agabi10 added a subscriber: Agabi10.Tue, Sep 3, 3:10 PM

Note that we've done minor version bumps e.g. from 7.0.0 to 7.0.13 for T209423 due to PHP bug https://bugs.php.net/bug.php?id=66862; would those kind of minor version changes be in scope for your 18 month guideline?

No.

Krinkle moved this task from Backlog to MediaWiki core on the PHP 7.0 support board.
Krinkle moved this task from Backlog to MediaWiki core on the PHP 7.1 support board.
Krinkle moved this task from Backlog to MediaWiki core on the PHP 7.3 support board.
kchapman edited projects, added TechCom-RFC (TechCom-Approved); removed TechCom-RFC.
kchapman added a subscriber: kchapman.

TechCom has approved this RFC.

Krinkle added a comment.EditedTue, Sep 17, 12:19 AM

That's another thing, the task description lacks any mention of WMF production, which has often been the sole reason for continuing to support a given PHP version.

This point was discussed during last week's TechCom meeting in evaluating the Last Call period. Based on the input we got from SRE and CPT, we believe it's desirable and expected for WMF to follow (at worst) the same Debian LTS timeline that we prescribe to third parties. Upgrading once per 2-3 years should be doable.

If and when a different situation emerges this can still be re-evaluated the old-fashioned way with a TechCom request on a case-by-case basis. In general, we expect this not to be necessary. Especially given that, with this RFC, the timeline will be more predictable going forward. Making it easier to plan for. We'll also still have a 6 months buffer between the start and end of a release cycle, during which the WMF upgrade could continue.

Change 534229 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[integration/config@master] layout: Drop php70 and php71 from quibble jobs for master and REL1_34

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

Change 534229 merged by jenkins-bot:
[integration/config@master] layout: Drop php70 and php71 from quibble jobs for master and REL1_34

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

Mentioned in SAL (#wikimedia-releng) [2019-09-17T00:29:01Z] <James_F> Zuul: Dropping php70 and php71 from quibble jobs for master and REL1_34 T228342

These are now "Defined". I suppose to Resolve this, the justifications and notes on actions under this new set of criteria (policy?) should be put up on MediaWiki.org somewhere?