This would effectively just kill the LTS effort if we can't adequately test releases and force people who care into using proprietary CI systems.

Looking at PHP's EOL isn't that useful - we really need to look at the Debian EOL, which for stretch/php7.0 is likely to be July 2020. So we're really looking at supporting stretch/php7.0 for an extra year after its EOL - I think we can handle that, especially in the new docker based setup.

Supporting the old PHP versions is a bit of a challenge for CI:
old versions have to be ported

That shouldn't be an issue going forwards since we can always use deb.sury.org now. In any case, I'm also a lot more familiar with Debian packaging now, and happy to help with these kinds of things.

we run extra tests which take time / resources

This isn't a problem in practice, because people rarely submit patches to these branches.

we have to keep using some old OS distribution (we already kept Ubuntu Precise past its end of life).

Using docker allows us to compartmentalize older distributions, so I'm significantly less worried/annoyed by this than I was in the past.

PHP 7.0 is end of life since January 10th 2019. Wikimedia already decided to migrate straight to PHP 7.2. I would like to drop the php 7.0 CI jobs entirely.

To be clear, we went to 7.2 directly because we needed features introduced in 7.1, and then because 7.2 had significant performance improvements. My understanding (from a few months ago) is that the eventual plan is to then move to 7.3 and stay in cadence with PHP versions included in Debian stable releases.

In T225628#5253393, @Legoktm wrote:

I think we can handle that, especially in the new docker based setup.

Which "we" are you expecting to do the work?

In T225628#5253647, @Jdforrester-WMF wrote:

In T225628#5253393, @Legoktm wrote:

I think we can handle that, especially in the new docker based setup.

Which "we" are you expecting to do the work?

Members of the virtual CI team, so me. I'd hope it's not just me that cares about providing good CI to all of our supported releases, but I feel confident that I can take it on as long as the rest of the docker infra continues to work.

The purpose is two folds:

• save us from having to maintain some old/obsolete versions of php. Though the Debian maintainer made PHP versions co installable and easier to forward port, it still comes at a price.
• run less jobs on CI. Having tests for all of hhvm, php 7.0, php 7.1 and php.7.2 use a bit of resources.

I get that the Docker containers makes it easy to support any arbitrary legacy state. But my point is really about CI still supporting use cases based on software which are way out of end of life.

I want to stop having to support legacy/obsolete softwares. php 7.0 is end of life, and if we were to support it for MediaWiki 1.31, that means we get to port php 7.0 until January 2021. Or 3 years after that PHP version got EOL. At that point, I don't think those tests would be any helpful since nobody would still be running PHP 7.0. In facts, nobody should be running php 7.0 already in June 2019.

I really do not want to keep dragging a Jessie container (which EOL in June 2020) and I do not want to put the effort to forward port php7.0 to a later Debian distribution. Debian packaging is a pain in the ass and nobody can assert what kind of madness we will have to face when porting it through years of libraries upgrades. Again, nobody is supposed to run php 7.0 anymore.

In the end, MediaWiki LTS claims to support an almost outdated PHP version at the time it is cut and we then have to support it for 3 years. Or another way to say it is that our 3 years LTS life cycle is outdated, it might have made sense a decade ago, but the whole industry has/is shifting toward quaterly (if not monthly) release cycles.

Some historical perspective:

MediaWiki 1.23 was cut in June 2014 and supported until May 2017. It claimed to support at least PHP 5.3 which went EOL in August 2014 just two months after the MediaWiki 1.23.0 release. Being a LTS version, CI had to keep Ubuntu Precise instance until MediaWiki went EOL.

T143349#3026648 was about getting rid of Precise. Eventually I got forced to drop php 5.3 support in CI and for sure the next MediaWiki LTS release was broken on PHP 5.3 since CI did not catch it. We had to release another hotfix release: https://lists.wikimedia.org/pipermail/mediawiki-announce/2017-April/000208.html

MediaWiki 1.27 still wanted to support PHP 5.5. Luckily that MediaWiki LTS is end of life as of this month of June 2019. Then PHP 5.5 went end of life 3 years ago (July 2016). I had to forward port the Debian packages to Jessie, it has been an interesting jigswaw challenge working with the half broken Debian packaging toolchain, but in the end I would really not have to do it.

My conclusion is: I do not want CI to have to maintain the infrastructure to run test for software which has been dead (end of life) for three years. Or in other terms, this task is about having MediaWiki LTS release to no more be validated against EOL software but just against the oldest currently maintained PHP version. As of today, that means dropping PHP 7.0 entirely, and potentially have the next MediaWiki release to add a note about php 7.2 being the only version that has been tested.

run less jobs on CI. Having tests for all of hhvm, php 7.0, php 7.1 and php.7.2 use a bit of resources.

I agree fast CI throughput is a priority, but from what I can see this isn't affected in practice given that the older PHP versions would only be run on patches for the REL branches, not master or wmf.

It only has to run on master as long as MediaWiki master supports those PHP versions. We can and most definitely should drop PHP 7.0 support for MW 1.34 (master) because it makes no sense for a future release to start by supporting an already EOL version of PHP. I can think it is generally fair not to invest significant resources in providing new features for installations not yet ready for a major upgrade (they can continue to use the LTS, that's what LTS is for after all).

This means at least for CI system resourcing, we won't notice the overhead (given REL patches are rare).

In T225628#5254616, @hashar wrote:

php 7.0 is end of life, and if we were to support it for MediaWiki 1.31, that means we get to port php 7.0 until January 2021. Or 3 years after that PHP version got EOL. At that point, I don't think those tests would be any helpful since nobody would still be running PHP 7.0. In facts, nobody should be running php 7.0 already in June 2019.

28% of all MediaWiki installations use PHP 7.0, 19% use 5.6, 3% use 5.5 per pingback. (That's pretty good by PHP standards, according to W3Techs 65% of PHP-based websites use PHP 5 or older, and another 11% use 7.0.)

In the end, MediaWiki LTS claims to support an almost outdated PHP version at the time it is cut and we then have to support it for 3 years. Or another way to say it is that our 3 years LTS life cycle is outdated, it might have made sense a decade ago, but the whole industry has/is shifting toward quaterly (if not monthly) release cycles.

The whole industry of what? Symfony has 3+1 year LTS support (the current LTS, which has two and half years more to go, still supports PHP 5.5), for example.
(OTOH Drupal, which also has very long although less regular support cycles, does automatically drop support for old PHP versions as they arrive at end of life, so that model is not that unusual either.)

My conclusion is: I do not want CI to have to maintain the infrastructure to run test for software which has been dead (end of life) for three years. Or in other terms, this task is about having MediaWiki LTS release to no more be validated against EOL software but just against the oldest currently maintained PHP version. As of today, that means dropping PHP 7.0 entirely, and potentially have the next MediaWiki release to add a note about php 7.2 being the only version that has been tested.

IMO it is unhelpful to have such a discussion framed in terms of CI support when what's actually being discussed is whether the MediaWiki LTS should support old PHP versions (I'm sure we all agree that claiming to support them but not having CI for it wouldn't be reasonable), in other words whether "LTS" means "if you install this version you don't need to upgrade for 3 years" or "if you install this version you don't need to upgrade MediaWiki for 3 years but might need to upgrade your system dependencies" (and potentially your other PHP applications because of that). Which is a discussion that should be had with a wider audience, IMO.

I'm sure we all agree that claiming to support them but not having CI for it wouldn't be reasonable

No, that's specifically what Antoine is proposing in this task. Dropping formal MW support for PHP 7.0 is T216165.

In T225628#5262875, @Jdforrester-WMF wrote:

No, that's specifically what Antoine is proposing in this task. Dropping formal MW support for PHP 7.0 is T216165.

That's dropping formal support in master. The discussion here amounts to dropping support retroactively in existing releases which were released with that support.

The discussion here amounts to dropping support retroactively in existing releases which were released with that support.

Yes. I would like to drop php7.0 entirely from the CI infrastructure. Which implies CI would no more test old release branches against php7.0 since it is EOL anyway and thus implies T216165.

php7.0 went EOL in January 2019 and we released MediaWiki 1.32 the same month claiming to support php7.0. Most probably php7.0 should have been formally dropped at that point.

In T225628#5267723, @hashar wrote:

php7.0 went EOL in January 2019 and we released MediaWiki 1.32 the same month claiming to support php7.0. Most probably php7.0 should have been formally dropped at that point.

Maybe, but it would not have made any practical difference for CI complexity - 1.32 is supported until the end of 2019, while 1.31 is supported until mid-2021. 1.35 will be the first release which needs to be supported beyond 1.31's EOL.

Change 516838 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[integration/config@master] [WIP] layout: Skip PHP70 and PHP71 jobs for MW master

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

Change 516838 abandoned by Jforrester:
[WIP] layout: Skip PHP70 and PHP71 jobs for MW master

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

Not a blocker to T216165. However, not Declining out-right, as keeping php70 going is not free.

The PHP 7.0 and 7.1 jobs have been removed from the pipelines for the master branch! T216165 T216166