This conversation has led the TechCom to consider T120164: RfC: Institute "last call" period for MediaWiki RfCs. Please direct procedural comments about the handling of this RFC to that task, so that we can focus this conversation on the required minimum PHP version for MediaWiki 1.27.

In T118932#1846878, @tstarling wrote:

@Betacommand clarified on IRC that he supports reopening the RFC for review. So, let's do that.

By continuing to discuss it here, or scheduling a follow-up conversation on IRC? Fine by me either way.

In T118932#1846921, @Tgr wrote:

Everyone is arguing about LTS releases but in the IRC discussion it was claimed that we might not even have any more LTS releases after 1.23. We really should decide that first.

As of now, we (Release-Engineering-Team) haven't lead yet the discussion whether the next MediaWiki version (1.27) will be a LTS or not nor we know whether we will continue providing LTS. That is probably going to be another RFC.

A note, code requiring Zend 5.4+ can not land yet due to CI running tests under Ubuntu Precise and Zend 5.3.

In T118932#1847059, @ori wrote:

By continuing to discuss it here, or scheduling a follow-up conversation on IRC? Fine by me either way.

Since one criticism was that IRC was not inclusive enough, let's discuss it here for now. I think we will eventually need to set up a Wikipedia-style vote page on mediawiki.org since it's hard to keep track of everyone's opinion on Phabricator.

In T118932#1847575, @tstarling wrote:

In T118932#1847059, @ori wrote:

By continuing to discuss it here, or scheduling a follow-up conversation on IRC? Fine by me either way.

Since one criticism was that IRC was not inclusive enough, let's discuss it here for now. I think we will eventually need to set up a Wikipedia-style vote page on mediawiki.org since it's hard to keep track of everyone's opinion on Phabricator.

Or we could vote here :)

In T118932#1847337, @hashar wrote:

In T118932#1846921, @Tgr wrote:

Everyone is arguing about LTS releases but in the IRC discussion it was claimed that we might not even have any more LTS releases after 1.23. We really should decide that first.

As of now, we (Release-Engineering-Team) haven't lead yet the discussion whether the next MediaWiki version (1.27) will be a LTS or not nor we know whether we will continue providing LTS. That is probably going to be another RFC.

Barring a discussion about not doing LTSes anymore, we are doing LTS. I think my idle thoughts about not doing LTS (in the vague hand-wavey future) have turned into a vicious rumor regarding 1.27.

I'd like to set the record clear: 1.27 will be LTS.

In https://lists.wikimedia.org/pipermail/wikitech-l/2015-December/084203.html @csteipp wrote:

So if we do LTS's, I would vote that we try to keep the php version the same for the LTS and following 3 non-LTS releases, if possible.

If we follow that advice (which is probably good advice from the point of view of being able to backport critical patches) and we don't bump the PHP minimum version for the 1.27 LTS release then we will need to maintain PHP 5.3 compat through the 1.30 development cycle which would end sometime in late 2018/early 2019.

This is only conjecture on my part, but I feel that being locked into only using 3rd party PHP libraries and tools that maintain PHP 5.3 support for that long will cause use a lot of heartache. PHPUnit 5.x is already requiring PHP 5.6+ and other projects are likely to follow with PHP 5.5 hitting the end of security support upstream on 2016-07-10. This doesn't mean that we are required to do so as well, but it will limit our options for collaboration and reuse.

I agree with @bd808: We should, in the long run, keep level with PHP development. If they churn out a new version of PHP every year, we can still say on the same version for two or three years, but then we should skip ahead two or three versions, to keep up. Otherwise, we fall behind more and more, until the version we support is considered deprecated by platform distributors.

Technically, it is enough to ensure forward compatibility. But maintaining compat with an ever growing number of PHP versions is not sustainable in the long run, ı think. Especially when we start using more 3rd party libraries.

"If one other person (any pre-existing Phabricator user) wants to put their name down as being unequivocally opposed to releasing 1.27.0 with a PHP 5.5 requirement" Barring better arguments for 5.5 than "has some neat stuff we would like to maybe use", and as someone who has hacked production code to get MW installed on machines with a too-low-but-still-works PHP versions :), I'm opposed for now.

Since 1.27 is planned to be LTS version, if we keep it on 5.4 that effectively means we'd have to still support and run 5.4 somewhere in 2019, when this PHP version would be 4 years past EOL. I have hard time believing distros would be able to efficiently backport fixes for all of those 4 years, especially given that PHP 7 engine already diverged significantly from PHP 5 one and that is likely to continue, so backporting fixes may become very non-trivial. And for third-party libraries and tools most likely nobody would support them so far back. So we also will be stuck with ancient versions of all tools and libraries (or, for those recent enough, without them at all). I don't think it is a good situation to find ourselves in. We're not living in a vacuum but in an ecosystem, and getting too far out of sync with it would add a lot of work for us.

From that POV also keeping on 5.3 seems to me really really really bad idea.

I made a quick user survey. Anyone have comments on it before I post a link to the mailing lists?

Should probably account for running multiple PHP versions, like Wikimedia does.

In T118932#1851119, @tstarling wrote:

I made a quick user survey. Anyone have comments on it before I post a link to the mailing lists?

We should also ask what version of MediaWiki they are currently using, and how often they update.

And while we're at it: a free-form text area for general comments to MediaWiki developers, and a checkbox for giving us permission to reach out if we have further questions. This would not be relevant to the immediate question at hand, but if we're doing something like this survey we might as well use the opportunity to solicit general feedback and to build relationships.

In T118932#1851122, @Krenair wrote:

Should probably account for running multiple PHP versions, like Wikimedia does.

I added help text "If you are running multiple versions of PHP, please indicate the lowest version you have in production."

In T118932#1851127, @ori wrote:

We should also ask what version of MediaWiki they are currently using, and how often they update.

And while we're at it: a free-form text area for general comments to MediaWiki developers, and a checkbox for giving us permission to reach out if we have further questions. This would not be relevant to the immediate question at hand, but if we're doing something like this survey we might as well use the opportunity to solicit general feedback and to build relationships.

If it's overcomplicated or creepy, people won't fill it out. Asking for general comments would imply that I'm going to read them and respond to them.

I added a MediaWiki version question.

In T118932#1851158, @tstarling wrote:

I added help text "If you are running multiple versions of PHP, please indicate the lowest version you have in production."

Wouldn't be more interesting to know the highest PHP version available on production and not the lowest, since the problem we're trying to address is what minimum version we should support?

Hey all,

I ran across this when I was catching up on the wikitech-l mailing list archive. I work for Rackspace Hosting, and maintain several private MediaWiki wikis for technical documentation.

I think this discussion should remain open for a while longer to try and gather input from other private wikis, like myself, who may have missed this over the holiday.

A version bump to 5.5 wouldn't be a huge issue for my wikis, especially since we make heavy use of SMW and would need to do so (or higher) anyway; however, it may be it may be a bigger deal for other corporate private wiki's out there.

--R

I don't understand the implications. I'm running PHP 5.3.8.

What do I get, and what does it cost, to upgrade to ≥5.5?

I'm running MediaWikis 1.13, 1.14, and 1.16.2. I would like to get back in sync, but somewhere along the line, I got badly burned in an upgrade.

What is the perceived safety of yanking those sites up to current? What are some pitfalls to look out for?

(To be fair, I had modified MediaWiki files when I upgraded before. I don't do that any more. :-)

In T118932#1853948, @Bytesmiths wrote:

I don't understand the implications. I'm running PHP 5.3.8.

What do I get, and what does it cost, to upgrade to ≥5.5?

I'm running MediaWikis 1.13, 1.14, and 1.16.2. I would like to get back in sync, but somewhere along the line, I got badly burned in an upgrade.

What is the perceived safety of yanking those sites up to current? What are some pitfalls to look out for?

(To be fair, I had modified MediaWiki files when I upgraded before. I don't do that any more. :-)

Depends on the OS etc you're running. Or your web host.

In most cases, upgrading your OS to a newer version (such as Ubuntu 12.04 to 14.04 etc) will do it as part of the upgrade

Composer reports the PHP version to packagist.org. There are some statistics from November 2015 (and November 2014) on a blog post at http://seld.be/notes/php-versions-stats-2015-edition

Note it is totally biased since composer is probably mostly used by developers or CI systems.

Composer versions

The very lame graphs:

Requirements in packages

All the above by Jordi Boggiano, http://seld.be/notes/php-versions-stats-2015-edition

@MikeHansenMe and @Ipstenu, could either of you help us discover touch-points the MediaWiki community could reach out to in decision making like this to reflect the usage in shared hosting environments (such as Bluehost and Dreamhost)?

I think it's a bad idea to forbid traits. Much like it's a bad idea to forbid global state, highly complex methods etc. While these are things that have serious downsides, should typically not be used, and of which most existing use cases are bad (at least in MediaWiki), there are places where their usage makes sense even to clean code advocates like me.

Change 258175 had a related patch set uploaded (by Albert221):
Updated todo to refer to T118932

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

22:58:15 <ori> #action legoktm / James_F to try using phpcbf to convert to [] and then enforce it

upstream comes with a Generic.Arrays.DisallowLongArraySyntax sniff, which can be used with phpcbf to convert array( ... ) into [ ... ], and will fail any usage of the long syntax.

Survey results

Auto-generated charts: https://docs.google.com/a/wikimedia.org/forms/d/1Z-io754bUxVujh100D4xvIwkiBIFk9Ef0j4TYrJ2zMc/viewanalytics
Raw responses and analysis: https://docs.google.com/spreadsheets/d/1kT4l4TiewtsJYNmx6UfX9xDqrhWBcpw1fKrgbd55oMc/edit

Difficulty by PHP version

.

Difficulty by PHP version, but with duplicates omitted (submitted this form before = no)

.

MW version vs PHP version (duplicates omitted)

.

MW version bucketed (duplicates omitted)

Adding this as a 1.27 blocker because I think we'd like this issue to be resolved before that is released.

Change 258175 abandoned by Hashar:
Updated todo to refer to T118932

Reason:
Not much need to point land a commit that tweak a comment. When we come to get Traits in MediaWiki this part of the code will be a candidate for Traits and the comment get removed automagically :-}

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

This came up during the developer summit in the past week a few times (in the hallway, nothing official). Here's the situation as I see it:

• PHP 5.3, and 5.4 are EOL and no longer supported by upstream (https://secure.php.net/supported-versions.php). Some Linux distros might offer support though
• @csteipp has asked that releases after the LTS use the same version requirement for ease of security backports. I think this is a reasonable request, and provides assurances to users that after we bump requirements in 1.27, we won't do that again for a while.
• MW 1.27 will be a LTS, and will be supported until May 2019. This will be 5! years after upstream stopped providing security support for 5.3.
  • LTS releases are ones where we make breaking changes, not immediately after (c.f. T118932#1846900)
  • It's highly likely someone will find an exploitable vulnerability in PHP 5.3 that can be exploited through MediaWiki (e.g. image uploads), defeating the point of providing security support for it.

So, IMHO releasing 1.27 with 5.3 support is an untenable position. The question then becomes, what minimum version to require?

• Wikimedia has servers running 5.5, so we can't go past that (https://tools.wmflabs.org/bash/quip/AU7VVvvk6snAnmqnK_z3)
• 5.4 is already EOL by upstream, and will have been unsupported for 4 years in May 2019. I think the same logic from 5.3 applies here, just one year less severe and no exclamation mark.

So that leaves 5.5. That's not really great either (from a security support perspective), as it will be 3 years EOL when 1.27 goes EOL, but it's a significant improvement over 5.3 (security and feature-set wise) that I think most people would be fine with it until 1.31 (wow!) comes around and we re-evaluate. 1.23.x will be supported until May 2017, so users will have roughly a year and a half to upgrade OR decide to stick with an EOL PHP, and run EOL MediaWiki with it.

As @csteipp said on IRC, we should specify a minimum point release as well for completeness sake. I haven't done much research into that yet.

In T118932#1916514, @tstarling wrote:

Difficulty by PHP version

	5.3	5.4	5.5	5.6
unspecified	0	4	0	0
easy	1	1	2	2
moderate	2	3	3	2
hard	4	5	4	1
very hard	12	4	1	3

.

This doesn't surprise me very much, for people who it was easy to upgrade would have done so a while ago, most of the people left are because they simply can't (very hard).

Note that supporting a 5.3 LTS means either having an unsafe package on CI cluster or having no CI for this MW version, resulting in a risk of making a broken release. I vote for re-closing this and moving forward. I think Tim has summed it up nicely about not upgrading PHP:

The criminals of the internet depend on people like you who don't care about security. You are an essential part of their infrastructure.

We should not encourage this even further.

+1 from me to re-close this, ideally with a change made to allow traits in ApiMessage and with an extended deadline for a decision on traits

In T118932#1929716, @MaxSem wrote:

Note that supporting a 5.3 LTS means either having an unsafe package on CI cluster or having no CI for this MW version, resulting in a risk of making a broken release.

As discussed above, this will eventually happen whatever PHP version we choose. There is simply too much difference between the length of the PHP release cycle and the MediaWiki LTS release cycle.

That said, the arguments about security backports and about doing the breaking changes in the LTS releases are convincing. +1 to requiring 5.5 for MW 1.27.

As a side note, I'd recommend watching PHP 5.5 changelog - everything that gets committed there is a security issue present in 5.3 and 5.4, which is not fixed there (unless somebody backports it). I don't see anything recently that has obvious (to me) exploit potential for MediaWiki (no idea about extensions) but there may be non-obvious things and bugs never stop coming.

I think we're looking at 5.5.9 for the min version.. That's what 14.04 is shipping, and for whatever reason, other projects like symfony/process 3.0 have chosen

In T118932#1929773, @Tgr wrote:

In T118932#1929716, @MaxSem wrote:

Note that supporting a 5.3 LTS means either having an unsafe package on CI cluster or having no CI for this MW version, resulting in a risk of making a broken release.

As discussed above, this will eventually happen whatever PHP version we choose. There is simply too much difference between the length of the PHP release cycle and the MediaWiki LTS release cycle.

Practically speaking, there is a huge difference: Ubuntu 14.04 LTS comes with PHP 5.5 and will be supported until 2019. You can't get anything like that for PHP 5.3.

In T118932#1932051, @MaxSem wrote:

Practically speaking, there is a huge difference: Ubuntu 14.04 LTS comes with PHP 5.5 and will be supported until 2019. You can't get anything like that for PHP 5.3.

How is that a practical difference? PHP 5.5 stops getting security fixes six months from now. (link) Is Ubuntu going to write/backport security fixes themselves?

In T118932#1932148, @Tgr wrote:

In T118932#1932051, @MaxSem wrote:

Practically speaking, there is a huge difference: Ubuntu 14.04 LTS comes with PHP 5.5 and will be supported until 2019. You can't get anything like that for PHP 5.3.

How is that a practical difference? PHP 5.5 stops getting security fixes six months from now. (link) Is Ubuntu going to write/backport security fixes themselves?

That's what they did for 5.3 in 12.04 LTS.

I agree that we should target 5.5.9 as minimum. I don't want to see us stuck with PHP 5.4 like we are with 5.3 now and I don't see the point for doing such a "baby step".

In general, we should move away from 5.3 rather sooner than later. There are so many pain points with supporting it still and it only gets more painful over time. Libraries start to drop support for it and the number of workarounds to keep it from segfaulting or doing other weird stuff is ever growing ….

In T118932#1945645, @hoo wrote:

I agree that we should target 5.5.9 as minimum.

In T118932#1916514, @tstarling wrote:

Survey results

I don't know if the plan is to ignore the stats or not, but what that survey seems to say is:

• 30% of the user base would be abandoned if PHP 5.3 was dropped [1]
• 47.5% of the user base would be abandoned if PHP 5.4 was dropped [2]

If this is at all indicative (and if it isn't, then I would like to see some alternative figures as a counter-example), then dropping support for PHP 5.4 (and even 5.3) will have a major impact on our existing users.

[1] 12 out of 32 respondents (37.5%) use MW >= 1.23 on PHP 5.3.
12 out of 15 (80%) of PHP 5.3 users would find it hard or very hard to upgrade.

[2] 12+8 out of 32 respondents (62.5%) use MW >= 1.23 on PHP 5.3+5.4.
19 out of 25 (76%) of PHP 5.3+5.4 users would find it hard or very hard to upgrade.

I have ignored the users of MW <= 1.22, but including them would increase the usage by about 2% in each case.

In T118932#1946807, @HappyDog wrote:

If this is at all indicative (and if it isn't, then I would like to see some alternative figures as a counter-example), then dropping support for PHP 5.4 (and even 5.3) will have a major impact on our existing users.

Yes. Nobody wants to support 5.3 for the next 3 years, 2 of which it will be completely out of even distro support.

In T118932#1946807, @HappyDog wrote:

In T118932#1916514, @tstarling wrote:

Survey results

I don't know if the plan is to ignore the stats or not, but what that survey seems to say is:

• 30% of the user base would be abandoned if PHP 5.3 was dropped [1]
• 47.5% of the user base would be abandoned if PHP 5.4 was dropped [2]

We're not abandoning them. They would get a year and a half to upgrade (when 1.23 becomes unsupported), at which point they can upgrade PHP, or they can continue to use EOL MediaWiki alongside their EOL PHP. I don't see that as unreasonable.

If this is at all indicative (and if it isn't, then I would like to see some alternative figures as a counter-example), then dropping support for PHP 5.4 (and even 5.3) will have a major impact on our existing users.

---

[1] 12 out of 32 respondents (37.5%) use MW >= 1.23 on PHP 5.3.
12 out of 15 (80%) of PHP 5.3 users would find it hard or very hard to upgrade.

[2] 12+8 out of 32 respondents (62.5%) use MW >= 1.23 on PHP 5.3+5.4.
19 out of 25 (76%) of PHP 5.3+5.4 users would find it hard or very hard to upgrade.

Well yes. As I said earlier, the majority of people still on PHP 5.3 and 5.4 probably will find it very hard to upgrade, because if it weren't, they would have upgraded years ago like everyone else!

Also, the survey isn't the whole picture, it's just people who read and responded to Tim's mediawiki-l post (I don't think it was advertised anywhere else?). I think the WikiApiary stats in T118932#1813219 show a much broader picture, where a large majority of users are already on 5.5 or 5.6.

Also, with Tim's mediawiki-l post, users of PHP versions < 5.5 had more motivation to vote and are probably overrepresented.

In T118932#1946807, @HappyDog wrote:

I don't know if the plan is to ignore the stats or not, but what that survey seems to say is:

• 30% of the user base would be abandoned if PHP 5.3 was dropped [1]
• 47.5% of the user base would be abandoned if PHP 5.4 was dropped [2]

For those votes, do we know if they are already on unsupported MediaWiki versions? Because if they are, raising PHP requisites for next MediaWiki version probably won't make much difference for them if they're already stuck in old MediaWiki versions for other causes.

In T118932#1949384, @Ciencia_Al_Poder wrote:

For those votes, do we know if they are already on unsupported MediaWiki versions? Because if they are, raising PHP requisites for next MediaWiki version probably won't make much difference for them if they're already stuck in old MediaWiki versions for other causes.

The raw data in T118932#1916514 also has the MW version.

This RfC is nominally about "MediaWiki core", but I imagine the vast majority of people consider that it would also cover at least the extensions in the MediaWiki tarball – WikiEditor, Gadgets, ParserFunctions, SpamBlacklist, Cite, Renameuser, etc. – which are nominally the responsibility of the Editing department here at the Wikimedia Foundation, and thus, in part, mine, as product lead for Editing.

Had Wikimedia not chosen to move to HHVM over Zend, this point would have likely been reached a year or more ago. As it is, it's now long past the point of reasonability to encourage people to keep using software in environments that have known security issues. Indeed, I believe it's unethical for us to effectively endorse this risky behaviour.

As a former third-party MediaWiki install owner for thousands of 'corporate' users, I understand the desire to maintain reasonable backwards-compatibility, something that I feel MW does better than other software for which I was also the owner (mentioning no names). However, though 'reasonable' is in the eye of the beholder, it's getting difficult to justify bending over backwards to support an EOL'ed piece of server-side software. (We are softer on backwards-support for client-side software due to the greater difficulties client-side users may have in changing their environments.)

I do not think we should 'accidentally' drop backwards-compatibility support, and there won't necessarily be a mad rush to break everything everywhere, but new versions will likely end up including code that just works better without hacks for 5.3 or 5.4 support.

Note that WMF teams do depend on PHP upgrade in their goals.

• Discovery wants to upgrade to Elasticsearch 2 which would incur an Elastica upgrade. Elastica versions that support ES2+ require PHP 5.4.
• Right now, I'm working on integrating https://github.com/jmikola/geojson into Kartographer (deploying which is a goal for this quarter). Without JsonSerializable support that comes with PHP 5.4 I would need to write silly emulation. I don't think that people who donated their money on upkeep and improvement of Wikipedia had this kind of work in mind.

ArchCom approved this at the 21:00 UTC ArchCom (private) meeting. We're discussing the ramifications/followups in E137: RFC Meeting: MediaWiki's PHP version requirement (2016-01-27, #wikimedia-office IRC channel)

Without JsonSerializable support that comes with PHP 5.4 I would need to write silly emulation.

You are not alone! BookManagerv2, Echo, EventLogging, Flow and MassAction all refers to it JsonSerializable. Then it is just an interface with a simple method. MassAction has 5.3 compatible layer. Hardly a blocker for Kartographer imho.

Dead horse. Why kick it? :P

tongue-in-cheek :-] Sorry!

@Danny_B #RfC "not meant for Wikimedia's Architecture committee (which should have TechCom-RFC instead)". @Legoktm added TechCom-RFC, removed #RfC