Page MenuHomePhabricator

Drop PHP 7.0 support from MediaWiki
Closed, ResolvedPublic

Description

PHP 7.0 lost security support at the end of 2018.

Related Objects

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 14 2019, 6:56 PM
Anomie added a subscriber: Anomie.Feb 14 2019, 7:16 PM
Legoktm changed the task status from Open to Stalled.Feb 14 2019, 7:45 PM
Legoktm added a subscriber: Legoktm.

Presumably this task will depend upon a TechCom-RFC to bump the minimum PHP requirement for MediaWiki 1.35, the next LTS.

Presumably this task will depend upon a TechCom-RFC to bump the minimum PHP requirement for MediaWiki 1.35, the next LTS.

I don't imagine we'll wait that long. It's already in security hell.

Krinkle added a subscriber: Krinkle.EditedFeb 14 2019, 9:26 PM

Presumably this task will depend upon a TechCom-RFC to bump the minimum PHP requirement for MediaWiki 1.35, the next LTS.

Yeah. Targeting the next LTS (MW 1.35; June 2020-2023) with removal of PHP 7.0 support seems fine by me. Although I suggest we also drop it in the next stable release (MW 1.33; June 2019-2020).

The current LTS (MW 1.31; PHP 7.0+) is supported until June 2021, which will exceed PHP 7.0's EOL by 2.5 years, Debian 8 Jessie's LTS by 1 year, and Ubuntu 16's LTS by a month or so.

Not ideal I guess. We keep thinking about this every time when considering to drop support, which is a bit late in the game. We should probably start thinking about this when make stable and LTS release, and think ahead whether we want to release it with that level of support.

That would balance our story a bit to not just be about what minority of users with unsupported software we're wiling to support, but also makes us talk about the cost and resources required to support something in the first place before we commit to it.

Talking only about dropping kind of implies that's what we have is fine. That's not entirely true of course, but the point is to be less reactive and plan a little bit better.

So in sum: I propose framing the as RFC as: Which PHP versions will we support in MW 1.33?

Then, based on the feedback and data presented we can decide what (not) to support and for how long, which may for example, include dropping PHP 7.1 at the same time.

I suppose we can keep this task for tracking the work relating to removing the specific PHP version, and create a new task for the RFC.

Krinkle moved this task from Inbox to Watching on the TechCom board.
Tgr added a subscriber: Tgr.EditedFeb 14 2019, 10:27 PM

Distros:

  • Debian Stretch has 7.0. Based on past schedule Buster (with 7.3) is probably released late summer this year (and from there Stretch will get one year of support and two more years of LTS support). Jessie is PHP5 only (and only has LTS support, until next summer).
  • Ubuntu Bionic (18.04, current LTS, released last July) has 7.2. Xenial (16.04 LTS) has 7.0; is supported until 2021. (Trusty is PHP5 only and will have EOL this April; all other supported versions are newer than Bionic.)
  • For RedHat/CentOS, version 7 (fully supported until end of year, ciritcal security updates until 2024) and RHEL 6 (critical security updates only, until late 2020) both have PHP 7.3 (I think? per this and this, they don't have an official public package index)
  • For OpenSUSE TumbleWeed (the "forever release") has 7.3, Leap 15 has 7.2, Leap 42 has 7.0. (You'd think the Debian release naming conventions are confusing, until you find out that OpenSUSE 42.3 is followed by 15.0...) 42.3 is maintained until end of June.
  • Arch has 7.3.
  • OSX Sierra has 7.3

So if we want to make sure latest MediaWiki runs out of the box on the latest stable/LTS on all distros, 1.33 needs PHP 7.0 support (because Stretch) and 1.34 could use 7.2. If we want MW to also run on one older stable/LTS where the latest is brand new (say less than a year old) that would put the threshold to 1.35.

Tgr added a comment.Feb 14 2019, 10:49 PM

Major benefits from moving to 7.1: better typehints (nullable, void, iterable), nicer destructuring assignments ([] instead of list(), support for associative arrays), lots of errors becoming non-fatal.

Reedy moved this task from Backlog to MediaWiki core on the PHP 7.0 support board.Jun 8 2019, 11:50 PM

Change 516829 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] Bump PHP version requirement to 7.2.0+

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

I'd like to try to swing this around and instead look at what the highest PHP version is that we could require, for MW 1.33/34 (regular stable) and MW 1.35 (LTS).

This exercise makes the following (potentially controversial) assumptions:

  • We prefer not to support a PHP version beyond its EOL.
  • We prefer not to support an Ubuntu or Debian version beyond its EOL.
  • 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 a combination for at least 1 year, preferably 2.

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 …)

Now, let's see if we could require PHP 7.2 for MW 1.33+ and uphold the three assumptions.

The only combination we need to look at is Debian 9 Stretch with PHP 7.0. On that platform, we support MW 1.31 started June 2018, and supported until June 2021 (that's 3 years even). By then, 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.

It does mean however, that we don't support users who remain on a single Linux LTS for more than 2 years, but I don't see why we would need to support that. Given they can remain idle for 2 years, and then have another year to upgrade.

Unfortunately, I think it's too late to drop PHP 7.0 support in 1.33; it's already in RC stage. Otherwise, I think this is a good working approach (so, raise requirement to PHP 7.2 for MW 1.34).

daniel added a subscriber: daniel.Jul 3 2019, 5:30 AM

This is marked as being blocked on T225628: On CI, stop testing MediaWiki with php7.0 ahead of dropping support. Isn't that the wrong way around?

This is marked as being blocked on T225628: On CI, stop testing MediaWiki with php7.0 ahead of dropping support. Isn't that the wrong way around?

No. We can't increase the minimum PHP version of MW right now, as CI won't let you merge it (because Phan-SecCheck still runs on PHP70 only). Once that last item is moved to PHP72, we can drop PHP70 and PHP71 from MW's support matrix in master.

At the same time, we also drop the support of HHVM?

At the same time, we also drop the support of HHVM?

No, that's T192166, blocked by T176370. This task can proceed ahead of that one.

daniel edited projects, added TechCom-RFC; removed TechCom.Jul 10 2019, 9:38 PM
daniel moved this task from Inbox to Under discussion on the TechCom-RFC board.

This should be an RFC since it has wide ranging implications.

This should be an RFC since it has wide ranging implications.

Can you please go have an RfC on another task with Timo's proposal (which would also encompass T216166 ), rather than disrupt this task?

Can you please go have an RfC on another task with Timo's proposal (which would also encompass T216166 ), rather than disrupt this task?

Dropping support for a PHP version should not be done without an RFC. Whether that RFC is tracked in this ticket or in a subtask doesn't really matter. I suppose discussing 7.0 and 7.1 together makes sense though.

@Krinkle, do you want to turn your proposal into an RFC that would block this and T216166?

We shouldn't need to do an RFC for every single PHP version drop. Let's instead have an RFC to set a schedule like @Krinkle's that will cover us for the next few years.

Meanwhile, we should drop 7.0 ASAP, because it's already EOL. As long as we still support 7.0, we have to still run 7.0 in CI (without security updates), and as soon as we drop 7.0 from CI we've effectively dropped support for it. I suggest we expedite approving dropping 7.0, then have an RFC about what the support windows will be for 7.1, 7.2 and 7.3.

I'd like to try to swing this around and instead look at what the highest PHP version is that we could require, for MW 1.33/34 (regular stable) and MW 1.35 (LTS).
This exercise makes the following (potentially controversial) assumptions:

  • We prefer not to support a PHP version beyond its EOL.
  • We prefer not to support an Ubuntu or Debian version beyond its EOL.
  • 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 a combination for at least 1 year, preferably 2.

I like this idea of setting criteria rather than rehashing similar arguments each time. One additional criteria to consider:

  • 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 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).

Meanwhile, we should drop 7.0 ASAP, because it's already EOL. As long as we still support 7.0, we have to still run 7.0 in CI (without security updates), and as soon as we drop 7.0 from CI we've effectively dropped support for it. I suggest we expedite approving dropping 7.0, then have an RFC about what the support windows will be for 7.1, 7.2 and 7.3.

PHP 7.0 will get security support through the Debian LTS project (I expect). Note that CI has supported plenty of EOL software before, so I don't see any reason to rush on that account.

[Again, PLEASE have this conversation on a generic task, not here.]

greg triaged this task as Normal priority.Jul 23 2019, 8:50 PM

Change 516829 merged by jenkins-bot:
[mediawiki/core@master] Bump PHP version requirement to 7.2.0+

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

Jdforrester-WMF closed this task as Resolved.Tue, Sep 17, 1:39 AM
Jdforrester-WMF claimed this task.

Done. Live in master and will ship in MediaWiki 1.34.0+.