Page MenuHomePhabricator

Bump MediaWiki's minimum supported MySQL Version to 5.5.8
Closed, ResolvedPublic

Description

https://github.com/wikimedia/mediawiki/blob/master/RELEASE-NOTES-1.29#L283

MySQL 5.0.3+

5.0.3 seems to date back to 2005-03-23. Although there aren't a huge amount of new features, there are things like 5.7 introduced an ALTER TABLE syntax to rename indexes

5.7.1 dates back to 2013-04-23, so maybe "too new"...

5.6.2 dates back to 2011-04-11, Developer Milestone

We're supporting PHP 5.5.9, which is from 06 Feb 2014 http://www.php.net/ChangeLog-5.php#5.5.9 so maybe 5.7 is alright, and isn't too new?

The 1.30 development cycle has started, so now would seem a reasonable time to be upgrading, giving time for it to settle etc as necessary

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Reedy added a comment.Apr 3 2017, 1:32 PM

My host doesn't use 5.7. And it uses new technology. we can use mysql version detection to aim code at mysql 5.7+ only. Its better then going from 5.0.3 all the way to 5.7.

Sticking conditionals all over the place is not the way to increase code maintainability

I don't see any reason to just bump to 5.1, 5.5 seems nicely in the middle. Or at least 5.5

I am not saying we should do only 5.1 or 5.5 -I am saying that is absolutely minimum. Everything else is a win, except going, right now, over 10/5.6 because we are still thinking if the next upgrade should be 10.1/2 or 5.7 or 8.0 for WMF- and Mediawiki right now does not now support MySQL 5.6/5.7 properly as to make it by default (GTIDs, for example).

I don't see any reason to just bump to 5.1, 5.5 seems nicely in the middle. Or at least 5.5

I am not saying we should do only 5.1 or 5.5 -I am saying that is absolutely minimum. Everything else is a win, except going, right now, over 10/5.6 because we are still thinking if the next upgrade should be 10.1/2 or 5.7 or 8.0 for WMF- and Mediawiki right now does not now support MySQL 5.6/5.7 properly as to make it by default (GTIDs, for example).

Agreed, I would even say we should "discard" 5.1 (as it is super old) and go for 5.5 as the oldest MySQL version we support and onwards. That doesn't mean that mediawiki doesn't work on 5.1 of course.

Reedy added a comment.Apr 3 2017, 1:41 PM

Current MW code would barf and fall over at least at the installer point

		$version = $conn->getServerVersion();
		if ( version_compare( $version, $this->minimumVersion ) < 0 ) {
			return Status::newFatal( 'config-mysql-old', $this->minimumVersion, $version );
		}
	"config-mysql-old": "MySQL $1 or later is required. You have $2.",

Honestly not sure if we check it/bail out anywhere else (potentially, if we don't, we should. At least in the Updater, where we should be bailing out if we don't have the right version, to make it known to people that stuff might start breaking if they haven't read the RELEASE-NOTES etc)

When we should we bump mysql to 5.5? Before the next lts release or after it. There should also be an advanced notice for users to know that the mysql version they use should be updated before updating to a newer mw. Just so they are prepared and so they ask there host to upgrade mysql.

Reedy added a comment.Apr 3 2017, 1:44 PM

I also don't think expecting MySQL 5.5 is a stretch. Release date 2010-12-03

PHP 5.5.9 is 06 Feb 2014

Though, it does seem distros are a bit more lagging on MySQL versions

Just noticed 5.0.3 is a beta.. Dating from 2005 :D

Zppix added a subscriber: Zppix.Apr 3 2017, 1:48 PM

I say maybe change min requirement but don't completely cut support for the current requirement, and then slowly start forcing the new requirement as we go on?

When we should we bump mysql to 5.5? Before the next lts release or after it. There should also be an advanced notice for users to know that the mysql version they use should be updated before updating to a newer mw. Just so they are prepared and so they ask there host to upgrade mysql.

Next LTS is 1.31 potentially? I think that's far too long to wait.

1.27 will support 5.0.3, and is supported for a few years

I'm not sure we need an RfC (maybe we do?) but ArchCom guys should have a say for sure

I say maybe change min requirement but don't completely cut support for the current requirement, and then slowly start forcing the new requirement as we go on?

It'd be more being able to use newer features... I don't see any reason to not do it in one go

See also

My host doesn't use 5.7. And it uses new technology. we can use mysql version detection to aim code at mysql 5.7+ only. Its better then going from 5.0.3 all the way to 5.7.

Sticking conditionals all over the place is not the way to increase code maintainability

Zppix added a comment.Apr 3 2017, 1:56 PM

I say maybe change min requirement but don't completely cut support for the current requirement, and then slowly start forcing the new requirement as we go on?

It'd be more being able to use newer features... I don't see any reason to not do it in one go

Maybe we keep it the same for 1 month after 1.30 cycle starts then change then to give people time to switch over before completely having something broken, (or do a 1.30.1)

Reedy added a comment.Apr 3 2017, 1:57 PM

No, we're not bumping versions in point releases unless we found a show stopping bug. And even then, that could just prevent people upgrading due to not wanting to put the effort in.

I'm not sure we should wait for the next LTS, but I'm indifferent whether this bump makes it into 1.29 or 1.30

I would support bumping to 5.5 but not all the way to 5.7.

Zppix added a comment.Apr 3 2017, 1:59 PM

@Reedy then maybe we start work and bump it for 1.29, so we can instantly start using it when 1.30 starts cycle.

Reedy added a comment.Apr 3 2017, 2:00 PM

We could start using it in the few weeks left of 1.29 if we wanted

Zppix added a subscriber: hashar.Apr 3 2017, 2:02 PM

It couldn't hurt @Reedy,@hashar would this affect CI?

Also wikimedia uses mariadb 10.0 which says it uses mysql 5.6 features https://mariadb.com/kb/en/mariadb/what-is-mariadb-100/ no mention of 5.7.

It couldn't hurt @Reedy,@hashar would this affect CI?

This should not affect ci if we do it with 5.5.

We could start using it in the few weeks left of 1.29 if we wanted

Which version are you talking about @Reedy ? 5.5? 5.6? 5.7?

Reedy added a comment.Apr 3 2017, 2:13 PM

It couldn't hurt @Reedy,@hashar would this affect CI?

This should not affect ci if we do it with 5.5.

Right. We're using Jessie now, and even if we were still on trusty it wouldn't be an issue

We could start using it in the few weeks left of 1.29 if we wanted

Which version are you talking about @Reedy ? 5.5? 5.6? 5.7?

I think 5.5 is a reasonable step forward for now. Per the below too

I don't see any reason to just bump to 5.1, 5.5 seems nicely in the middle. Or at least 5.5

I am not saying we should do only 5.1 or 5.5 -I am saying that is absolutely minimum. Everything else is a win, except going, right now, over 10/5.6 because we are still thinking if the next upgrade should be 10.1/2 or 5.7 or 8.0 for WMF- and Mediawiki right now does not now support MySQL 5.6/5.7 properly as to make it by default (GTIDs, for example).

So your opinion has some weight, you'll have some domain knowledge, have a better understanding (without reading around too much like others would have to) of what improvements it'll bring etc

Let me do a table including my opinion about each version:

MariaDB 5.1MariaDB 5.2MariaDB 5.3MariaDB 5.5MariaDB 10.0MariaDB 10.1MariaDB 10.2MySQL 5.0MySQL 5.1MySQL 5.5MySQL 5.6MySQL 5.7MySQL 8.0
GA Release data2010-02-012010-11-102012-02-292013-03-052014-03-312015-10-17not released yet2005-10-192008-11-142010-12-032013-02-052015-10-21not released yet
Official EOLEOLEOLEOL2020-04-112019-03-312020-10-175 years after stable (GA) release dateEOLEOLDec 2015/Dec 2018Feb 2018/Feb 2021Oct 2020/Oct 2023Probably 5-8 years after realease
Mediawiki works well?yes, with sacrificesyes, with sacrificesyes, with sacrificesyesyesyesunknownyes, with sacrificesyes, with sacrificesyesyes, no GTID supportyes, no GTID support, no sql mode supportunknown
Reedy added a comment.Apr 3 2017, 2:25 PM

Thanks Jaime

I think one of the few downsides of 5.5 is the EOL being not so far away, but with our past support of MySQL, this isn't so much of an issue.

Plus, there's no reason we can't be more proactive bumping MySQL versions in the future, to 5.6 or 5.7 in a few MW releases time, when some of the older OS LTS go away, and then there is more MySQL 5.7 about, and further improvements have been made in MW to support the features we get from upgrading

Krinkle added a subscriber: Krinkle.EditedApr 4 2017, 1:40 AM

+1 for bumping the MySQL requirement 5.5.

https://www.mediawiki.org/wiki/Version_lifecycle

MediaWikiNoteReleasedEOL
1.29In developmentJune 2017June 2018
1.28Current stable2016-112017-11
1.27Current LTS2016-06-28June 2019
1.23Legacy LTS2014-06-05May 2017

https://www.mediawiki.org/wiki/Compatibility#PHP

Requirements in 1.23, 1.27 and current master (unchanged):

  • PHP: 5.5+
  • MySQL: 5.0+

To compare EOL dates, I'd rather compare to the release of the major version, not the latest minor version since updating a minor version is more trivial than updating a major version. The major version upgrade is imho indicative of when any given sysadmin might perform the next "major" upgrade.

Looking at https://www.mysql.com/support/supportedplatforms/database.html support for 5.0 and 5.1 has mostly evaporated, except for a platform vendors providing extended support for their legacy LTS versions. 5.5 has been supported for at least three major versions on most platforms. For example:

  • Ubuntu 12 Trusty and higher is supported for MySQL 5.5+.
  • Debian 7 Wheezy and higher is supported for MySQL 5.5+.

This, combined with the fact that our current LTS will continue to support MySQL 5.0 and 5.1 until June 2019 for anyone unable to upgrade seems like a strong indicator that we would be safe to update our requirements to MySQL 5.5.

We also have some good data from over 18,000 third-party wikis from WikiApiary:
https://wikiapiary.com/wiki/MySQL_Versions/non-wmf

MySQL version# wikis% of wikis
10.0537 wikis2.8%
5.7501 wikis2.6%
5.63,630 wikis19.1%
5.58,871 wikis46.7%
5.322 wikis0.1%
5.22 wikis0.01%
5.14,039 wikis21.1%
5.01,356 wikis7.1%
4.136 wikis0.19%
4.06 wikis0.03%

While the vast majority (over 65%) is on MySQL 5.5 or higher, MySQL 5.1 at 28% is still quite significant.

I ran a few more queries to combine this with information about PHP versions and got the following. This following is the same query but without wikis on PHP < 5.5, e.g. they are definitely not running any currently supported version of MediaWiki.

Wikis by MySQL version running PHP 5.5+ or PHP 7+

MySQL version# wikis%
MySQL 10.0479 wikis6%
MySQL 5.7448 wikis5%
MySQL 5.62,743 wikis32%
MySQL 5.54,098 wikis47%
MySQL 5.318 wikis0%
MySQL 5.21 wikis0%
MySQL 5.1736 wikis8%
MySQL 5.0143 wikis2%

This shows a much better picture. Over 90% already runs MySQL 5.5 or higher.

Raw queries
Using https://wikiapiary.com/wiki/Special:ExpandTemplates

# Query: wikis by MySQL on PHP 5.5+
{{#arraydefine: versions
 | 10.0, 5.7, 5.6, 5.5, 5.3, 5.2, 5.1, 5.0
}}{{#arrayprint: versions ||@@@@|<nowiki/>
* <strong>MySQL @@@@</strong> used on <strong>{{formatnum: {{#ask:
[[Has database major version::{{#explode:@@@@|.|0}}]]
[[Has database minor version::{{#explode:@@@@|.|1}}]]
[[Has PHP major version::5]]
[[Has PHP minor version::≥5]]
[[Is active::True]]
[[Has netblock organization handle::!WIKIM]]
| format=count }}}}</strong> wikis
}}

# Query: wikis by MySQL on PHP 7+
{{#arraydefine: versions
 | 10.0, 5.7, 5.6, 5.5, 5.3, 5.2, 5.1, 5.0
}}{{#arrayprint: versions ||@@@@|<nowiki/>
* <strong>MySQL @@@@</strong> used on <strong>{{formatnum: {{#ask:
[[Has database major version::{{#explode:@@@@|.|0}}]]
[[Has database minor version::{{#explode:@@@@|.|1}}]]
[[Has PHP major version::≥7]]
[[Is active::True]]
[[Has netblock organization handle::!WIKIM]]
| format=count }}}}</strong> wikis
}}

# Query: wikis on MySQL 5.6
# Result: 3,630
{{formatnum:{{#ask:
[[Has database major version::5]]
[[Has database minor version::6]]
[[Is active::True]]
[[Has netblock organization handle::!WIKIM]]
|format=count}}}}

# Query: wikis on MySQL 5.4 or higher
# Result: 12,638
{{formatnum:{{#ask:
[[Has database major version::5]]
[[Has database minor version::>5]]
[[Is active::True]]
[[Has netblock organization handle::!WIKIM]]
|format=count}}}}
hashar added a comment.Apr 5 2017, 9:56 AM

It couldn't hurt @Reedy,@hashar would this affect CI?

On the CI nodes we have:

Trustymariadb-server-core-5.5
Jessiemariadb-server-core-10.0

It is installed via integration/config.git:

dib/puppet/ciimage.pp
ensure_packages(['mariadb-client', 'mariadb-server'])

So that installs whatever version is available in apt.wikimedia.org.

tstarling moved this task from Inbox to Under discussion on the TechCom-RFC board.Apr 5 2017, 9:43 PM

I'm not sure we need an RfC (maybe we do?) but ArchCom guys should have a say for sure

Yes, I think it needs an initial wikitech-l announcement, then RFC meeting, then last call announcement, then final archcom approval. Best to do it by the book, considering the experience we had with T75901. Let me know when it's ready for an RFC meeting, or drag it into the relevant column on the archcom board.

Here are the new features I was able to find which may be of interest:

  • In 5.5 "The utf8mb4 character set has been added. This is similar to utf8, but its encoding allows up to four bytes per character to enable support for supplementary characters." Relevant to the installer since the installer help text recommends binary over utf8, due to the bytes per character limit in utf8. We may want to start using utf8mb4 instead.
  • In 5.1.6: event scheduler. This is actually quite interesting and has a few potential applications for us, especially for small installations where the admin is not aware of all the cron jobs they could be running. CheckUser data expiry (WMF uses a cron job), purging of expired rows from recentchanges, objectcache, ipblocks and page_restrictions. Currently these things have to be done during normal web requests, which is complicated, and when the web requests stop coming, the data sits around forever.

Two comments:

  • utf8mb4 only is up to date to the latest unicode standards on the latest MySQL versions. Not 100% sure I would recommend utf8mb4 from 5.5 nowadays- but it could be tested to see if it is good enough. It is much better than 3 byte utf8, no doubt
  • Events is something that springle liked a lot, and can be useful for some use cases. However, they have a lot of limitations, they are difficult to disable, easy to create lateral effects, etc. so I would not recommend them by default (as you say, only if there is not a better alternative).
Reedy added a comment.Apr 6 2017, 12:17 PM

Any advances on 5.5.8? We seem to have generally decided that the 5.5 branch is where we want to be (at least, to take forward to the RfC stage).

Any advance/specific reason to chose a higher point release than the initial GA at 5.5.8? Such as major show stopping bugs in some other early point release?

All distros with security support are updating to the latest 5.5.x release (since Oracle doesn't release enough information to backport security fixes), so it doesn't seem to far-fetched to mandate something later than 5.5.8

Reedy added a comment.Apr 6 2017, 12:34 PM

5.5.48 would be the first release of 2016, and 5.5.54 (and as of writing, currently released version) would be the last. None in 2017 yet

Considering 5.5.8 dates back to December 2010... Picking something generally newer, that someone mostly ontop of their security updates should have seems a good idea.

5.5.8 https://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-8.html

5.5.48 https://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-48.html

5.5.54 https://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-54.html

I think support and recommend are different stories. The recommendation is always to run the latest or some of the latest versions within a major version- but as a minimum version supported, we should not put barriers to that given no features are added after a GA (except show-stopped bugs). If someone wants to run version with security problems, we should advice, but not disallow.

For example, I would not recommend to anyone now using a MariaDB version lower than 10.0.30- but we have used almost all 10.0.X versions on the past with no major issues.

I believe we should not recommend but support, and for that I would say we support 5.5.8 (or the first GA).
There is nothing stopping us from saying that it is recommended to always run the latest stable release (within the same version), but that is up to everyone to decide what is best for them, their environment and all that

For MariaDB, is it the same version number?

Reedy added a comment.Apr 11 2017, 9:26 PM

For MariaDB, is it the same version number?

I think for 5.5 yes..

For when we only support mysql >= 5.6 and such newer versions, we will likely need different version handling for mariadb, as it jumps to the 10.1.22-MariaDB-1~yakkety

MariaDB version numbers follow the MySQL's numbering scheme up to version 5.5. Thus, MariaDB 5.5 offers all of the MySQL 5.5 features. There exists a gap in MySQL versions between 5.1 and 5.5, while MariaDB issued 5.2 and 5.3 point releases.
After the 5.5 version, MariaDB developers decided to start a branch numbered 10, as an attempt to make it clear that MariaDB 10.0 will not import all features from MySQL 5.6; however, they might be imported in future versions. Since specific new features have been developed in MariaDB, the developers decided that a major version number change was necessary

https://en.wikipedia.org/wiki/MariaDB#Versioning

Kghbln added a subscriber: Kghbln.EditedApr 11 2017, 9:29 PM

While the vast majority (over 65%) is on MySQL 5.5 or higher, MySQL 5.1 at 28% is still quite significant.

From my experience: I guess this is due to companies like 1and1. While they in the meantime update PHP on their servers if you like it or not they lack to do this for MySQL databases. In the meantime you cannot create new ones with 5.1 however if you e.g created a new database just a couple of years ago it was standardly 5.1 and you are still stuck with that. So I now have a wiki on PHP 5.6 with MySQl 5.1 - unbelievable but true. To migrate you have to export the database and import into an new 5.5.

This is just to provide an explanation why we still have a lot of 5.1 around and not a plea to keep anything below 5.5. Debian 8 is currently on 5.5.54 so I am cool and so should probably be MediaWiki with 5.5.x

@Krinkle wrote:

While the vast majority (over 65%) is on MySQL 5.5 or higher, MySQL 5.1 at 28% is still quite significant.

[..] So I now have a wiki on PHP 5.6 with MySQl 5.1 - unbelievable but true. To migrate you have to export the database and import into an new 5.5.

This is good to know, however please note that this figure ("MySQL 5.1 at 28%") is based on all MediaWiki and PHP versions. I ran a second query just looking at the ones running PHP 5.5+. In other words any wikis capable of running MediaWiki 1.23 (legacy LTS) or newer.

[..]
Wikis by MySQL version running PHP 5.5+ or PHP 7+

MySQL version# wikis%
MySQL 10.0479 wikis6%
MySQL 5.7448 wikis5%
MySQL 5.62,743 wikis32%
MySQL 5.54,098 wikis47%
MySQL 5.318 wikis0%
MySQL 5.21 wikis0%
MySQL 5.1736 wikis8%
MySQL 5.0143 wikis2%

This shows a figure of 8% instead of 28%, which would include your example of a hosting provider upgrading PHP but not MySQL.

This shows a figure of 8% instead of 28%, which would include your example of a hosting provider upgrading PHP but not MySQL.

Yeah, that's true. Thanks for emphasizing. Together with 5.0 users way too many wikis and the result of a somehow questionable upgrade path.

Normally, it is assumed that MariaDB 5.5 is MySQL 5.5 and MariaDB 10.0 "is" MySQL 5.6
MariaDB 10.1 is considered to be the "equivalent" of MySQL 5.7

hashar removed a subscriber: hashar.Apr 12 2017, 7:30 AM
Reedy added a comment.May 9 2017, 7:21 PM

Yes, I think it needs an initial wikitech-l announcement, then RFC meeting, then last call announcement, then final archcom approval. Best to do it by the book, considering the experience we had with T75901. Let me know when it's ready for an RFC meeting, or drag it into the relevant column on the archcom board.

I think we might aswell move forward with this to the RFC meeting. We don't seem to be having any real pushback (as long as we don't go "too new"), which was the idea anyway.

Things like T73566 become easier when we don't have < 5.5 support to worry about

Reedy renamed this task from Should we bump minimum supported MySQL Version? to Should we bump minimum supported MySQL Version to 5.5?.May 9 2017, 7:22 PM
Reedy updated the task description. (Show Details)
Anomie added a subscriber: Anomie.May 9 2017, 7:32 PM
jcrespo renamed this task from Should we bump minimum supported MySQL Version to 5.5? to Should we bump Mediawiki's minimum supported MySQL Version to 5.5?.Jun 20 2017, 6:50 AM

Renaming because phabricator contains other projects than mediawiki, so contextualizing better- mysql appears on many searches related to WMF infrastructure.

Kghbln renamed this task from Should we bump Mediawiki's minimum supported MySQL Version to 5.5? to Should we bump MediaWiki's minimum supported MySQL Version to 5.5?.Jun 20 2017, 6:52 AM
daniel moved this task from Under discussion to Last Call on the TechCom-RFC board.EditedJun 30 2017, 12:23 PM
daniel added a subscriber: daniel.

During the ArchCom meeting on June 28, it was agreed for this RFC to enter the Last Call period. If no pertinent issues remain unaddressed by July 12, this RFC will be approved for implementation.

During the discussion, there was agreement that we can assume that of the 10% of installs that are on MySQL versions older than 5.5, the vast majority is running an old version of MediaWiki anyway. Also, the recent LTS release of MediaWiki guarantees support for MySQL 5.0 for the next two years.

Not technically part of the the RFC, but the closer we get to 5.7, the closer this will become a problem: T108255 This is not meant to block this in any way; on the contrary, to bump the importance of that other task.

Since no objections have been raised during the last call period, this RFC has been approved for implementation.

Reedy added a comment.Jul 13 2017, 4:05 PM

Sweet, thanks.

Fine to go into 1.30?

I'll see about making some patches, and see what we can start to remoooove :D

daniel added a subscriber: demon.Jul 13 2017, 4:10 PM

Sweet, thanks.
Fine to go into 1.30?

I guess so, but ask @demon...

demon added a comment.Jul 13 2017, 4:13 PM

1.30? We haven't even begun yet. Go ahead

Change 365051 had a related patch set uploaded (by Reedy; owner: Reedy):
[mediawiki/core@master] [WIP] Bump minimum required MySQL Version to 5.5.8

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

This may require multiple changes on the official wiki documentation, you will need help to change all (which I offer).

This may require multiple changes on the official wiki documentation, you will need help to change all (which I offer).

Indeed. I wonder if we can get away with just changing it everywhere onwiki to say 5.5... OR we need the mw version caveat.

demon removed a subscriber: demon.Jul 13 2017, 8:05 PM

Change 365051 merged by jenkins-bot:
[mediawiki/core@master] Bump minimum required MySQL Version to 5.5.8

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

Reedy added a comment.Jul 17 2017, 6:51 PM

So just Documentation left to sort out...

Aklapper renamed this task from Should we bump MediaWiki's minimum supported MySQL Version to 5.5? to Bump MediaWiki's minimum supported MySQL Version to 5.5.8.Jul 17 2017, 7:24 PM

This may require multiple changes on the official wiki documentation, you will need help to change all (which I offer).

Indeed. I wonder if we can get away with just changing it everywhere onwiki to say 5.5... OR we need the mw version caveat.

Based on the name of https://www.mediawiki.org/wiki/Template:MW_stable_mysql_requirement once 1.30 is stable I think we can just update the number.

@Reedy we will want mariadb checks too unless it works with the mysql one?

What is the narrative? "5.5.X required. If you are restricted to 5.1 or 5.0, use Y version"? Should we warn against using unsupported mysql versions, or not our job?

Reedy added a comment.Jul 18 2017, 3:24 PM

What is the narrative? "5.5.X required. If you are restricted to 5.1 or 5.0, use Y version"? Should we warn against using unsupported mysql versions, or not our job?

For PHP we basically stop it working completely.

As things stand, with https://gerrit.wikimedia.org/r/365051 merged, it will just stop new installs. Old installs aren't checked/prevented or whatever (unless, I guess they use the installer to run the updater...). T162044 filed to address that, and make update.php actually check for ongoing compatibility. For PHP, we check it on loading of entry points, to prevent intelligible failures further down the actual stack (usually syntax errors as far as older PHP versions are concerned).

	"config-mysql-old": "MySQL $1 or later is required. You have $2.",
		// Check version
		$version = $conn->getServerVersion();
		if ( version_compare( $version, $this->minimumVersion ) < 0 ) {
			return Status::newFatal( 'config-mysql-old', $this->minimumVersion, $version );
		}

So we end up with something along the lines of

"MySQL 5.5.8 or later is required. You have 5.0.3"

@Reedy we will want mariadb checks too unless it works with the mysql one?

I believe divergence doesn't start till MySQL 5.6, so nothing to do here

Seb35 added a subscriber: Seb35.Aug 5 2017, 7:34 PM

Note the related task T120333 about deprecation of the PHP extension 'mysql'. From the only compatibility matrix between the PHP extension 'mysql' and MySQL server I found, Choosing an API explictely says the PHP extension 'mysql' is not compatible with MySQL 5.1, amongst other missing features.

Note the "Supports all MySQL 5.1+ functionality", which probably means it misses prepared statements and authentication features. We want 5.1 mostly for SQL and InnoDB improvements, so while I have all support for deprecating the mysql extension, this doesn't necessarily imply the referred ticket- but probably we should do it anyway.

Legoktm closed this task as Resolved.Oct 20 2017, 11:58 PM
Legoktm assigned this task to Reedy.

I've updated https://www.mediawiki.org/w/index.php?diff=2590440&oldid=602309&title=Template%3AMW_stable_mysql_requirement&type=revision since 1.30 will be released soon. I don't think there's anything else to do here, so marking as resolved. Please re-open if that's not the case.