Per Daniel.

This sounds good to me.

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

In T228342#5382501, @Legoktm wrote:

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?

In T228342#5411614, @Simetrical wrote:

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?

In T228342#5413531, @Simetrical wrote:

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.

In T228342#5416039, @RazeSoldier wrote:

[..] 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.

In T228342#5415977, @Simetrical wrote:

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.

In T228342#5415977, @Simetrical wrote:

[..] 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. :)

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.

looked at the wrong task :)

In T228342#5382855, @Jdforrester-WMF wrote:

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.

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

In T228342#5447215, @tstarling wrote:

In T228342#5382855, @Jdforrester-WMF wrote:

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.

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?

In T228342#5451888, @Jdforrester-WMF wrote:

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.

TechCom has approved this RFC.

In T228342#5447272, @tstarling wrote:

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?

Action item for self:

• Publish these guidelines convention on mediawiki.org.
• Document in our development policy that PHP support changes need to follow these guidelines, and (based on feedback from last week) that regardless of whether within the policy or not, that individual requirement changes should be announced on Wikitech-l every time at least one week before landing in master (purely as heads up for local dev envs and for sites like translatewiki.net, not an RFC),