In T161232#3150577, @jcrespo wrote:

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.

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.

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

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?

In T161232#3150633, @Paladox wrote:

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

In T161232#3150646, @Zppix wrote:

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

In T161232#3150573, @Reedy wrote:

In T161232#3150546, @Paladox wrote:

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

In T161232#3150708, @Reedy wrote:

In T161232#3150646, @Zppix wrote:

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)

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.

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

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

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.

In T161232#3150750, @Zppix wrote:

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

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

In T161232#3150740, @Reedy wrote:

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?

In T161232#3150755, @Paladox wrote:

In T161232#3150750, @Zppix wrote:

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

In T161232#3150756, @Paladox wrote:

In T161232#3150740, @Reedy wrote:

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

In T161232#3150577, @jcrespo wrote:

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:

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

+1 for bumping the MySQL requirement 5.5.

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

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.

• PHP 5.5 (5.5.0) was released in June 2013 (http://www.php.net/ChangeLog-5.php#5.5.0)
• MySQL 5.7 (first milestone: 5.7.1) was released April 2013 (https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-1.html).
• MySQL 5.6 (first milestone: 5.6.2) was released October 2011 (https://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-3.html)
• MySQL 5.5 (first milestone: 5.5.0) was released December 2009 (https://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-0.html)
• MySQL 5.1 was released November 2008 (info not available on mysql.com)

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

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+

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

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}}}}

In T161232#3150750, @Zppix wrote:

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

On the CI nodes we have:

It is installed via integration/config.git:

ensure_packages(['mariadb-client', 'mariadb-server'])

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

In T161232#3150649, @Reedy wrote:

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

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

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

Crossposted to mailing lists

https://lists.wikimedia.org/pipermail/mediawiki-l/2017-April/046494.html
https://lists.wikimedia.org/pipermail/wikitech-l/2017-April/087964.html

For MariaDB, is it the same version number?

In T161232#3173372, @Legoktm wrote:

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

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

In T161232#3173421, @Kghbln wrote:

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

In T161232#3152897, @Krinkle wrote:

[..]

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

MySQL version	# wikis	%
MySQL 10.0	479 wikis	6%
MySQL 5.7	448 wikis	5%
MySQL 5.6	2,743 wikis	32%
MySQL 5.5	4,098 wikis	47%
MySQL 5.3	18 wikis	0%
MySQL 5.2	1 wikis	0%
MySQL 5.1	736 wikis	8%
MySQL 5.0	143 wikis	2%

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

In T161232#3159527, @tstarling wrote:

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

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

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.

Sweet, thanks.

Fine to go into 1.30?

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

In T161232#3436141, @Reedy wrote:

Sweet, thanks.

Fine to go into 1.30?

I guess so, but ask @demon...

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

In T161232#3436277, @jcrespo wrote:

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.

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

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

So just Documentation left to sort out...

In T161232#3437495, @Reedy wrote:

In T161232#3436277, @jcrespo wrote:

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?

In T161232#3447181, @jcrespo wrote:

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"

In T161232#3446946, @Paladox wrote:

@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

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.