Upgrading PHP and MySQL support/requirements

[JoeMurray]

Our installation instructions (see http://wiki.civicrm.org/confluence/display/CRMDOC/Installation+and+Upgrades) indicate that CiviCRM requires PHP 5.3+ which is no longer a supported version (see http://php.net/supported-versions.php) and MySQL 5.1+ which is no longer under active development (see http://en.wikipedia.org/wiki/MySQL#Versions, and http://dev.mysql.com/doc/relnotes/mysql/5.1/en/ which suggests no security releases have come out in 2014).

I think at a minimum we should change the documentation to indicate that we support stable releases of PHP and MySQL. But I'm not familiar with whether there has been systematic testing of CiviCRM with newer versions of PHP or MySQL.

I don't think the breakages seen with PHP 5.3 are as common with PHP 5.4 (though dropping calltime pass by ref was a big one), 5.5 and 5.6, but I'm not sure (see http://php.net/manual/en/migration54.incompatible.php, http://php.net/manual/en/migration55.incompatible.php, and http://php.net/manual/en/migration56.incompatible.php).

MySQL incompatible changes introduced in 5.5 are documented at http://dev.mysql.com/doc/refman/5.5/en/upgrading-from-previous-series.html, and those for 5.6 are available at http://dev.mysql.com/doc/refman/5.6/en/upgrading-from-previous-series.html.

Perhaps we could run the CI tests on various combinations of PHP and MySQL.

I understand pingback data shows there is significant use of MariaDB and Percona for CiviCRM these days; certainly we have some sites that are using them. Because of the advantages of using these higher performance engines, I think it would be worth listing them as well as MySQL. Though again, we should likely do a CI run on them before listing them, despite their claims to drop-in replacement functionality for MySQL/InnoDB. Or we could indicate that they are commonly used if we don't want to invest in the testing.

[Coleman Watts]

I love the new shorthand array format introduced in PHP 5.4 and have been itching to start using it as soon as we officially drop support for php 5.3.

[totten]

FWIW, I'm less concerned with the php.net/mysql.com policies and more concerned with the distro policies. A quick summary of some major distros:

 * Debian 6 LTS, PHP 5.3, MySQL 5.1
 * Debian 7, PHP 5.4, MySQL 5.5
 * Ubuntu 12.04 LTS, PHP 5.3, MySQL 5.5
 * Ubuntu 14.04 LTS, PHP 5.5, MySQL 5.5/5.6
 * RHEL 6, PHP 5.3, MySQL 5.1
 * RHEL 7, PHP 5.4, MariaDB 5.5 ??

Source:
 * http://distrowatch.com/table.php?distribution=debian
 * http://distrowatch.com/table.php?distribution=redhat
 * http://distrowatch.com/table.php?distribution=ubuntu

It seems like we're now at a stage where every major distro has PHP 5.4+ and MySQL 5.5+ in their current LTS, so it might be OK to bump versions soon. I'd personally lean toward a version bump in 5.0 rather than 4.6 (but wouldn't object if out-voted).

FWIW, the civicrm.org infrastructure (testing, demos, etc) is running on Debian 6 and Ubuntu 12.04 (both PHP 5.3). A version bump will require updates to several c.o services. Based on past experience, I also expect some of the test-results to change when going to PHP 5.4.

Aside: There was a Q over email about testing and multiple versions. Jenkins does allow us to orchestrate+compare the tests across different VMs / different versions of PHP/MySQL. The main trade-offs are among performance (how long for tests to return) / resource-usage (how many VMs/how much RAM) / visibility (do we include in the PR-testing or in daily-testing).

[JoeMurray]

Makes sense to concentrate on major distros. At JMA our packages recently have mainly been determined by distro, except for cases where we have upgraded to MariaDB from MySQL. I believe the community often has reason to upgrade to newer more performant databases, but not really to upgrade to newer versions of PHP.

Still, as PHP 5.6 is quite backward compatible, it would be good to be able to say that we support all stable versions of PHP. I don't foresee issues here.

In the MySQL 5.6 Incompatible Changes I see a change in the storage of times which may cause various issues that will need to be tested over database upgrades to MySQL 5.6. However, I'm not sure if having fractions on times will cause any odd / bug behaviour in our codebase; I would assess the risk as low but not zero. It would be nice to be able to claim compatibility with this stable version since it is claimed to be much more performant than 5.5.

As important is to assess compatibility of MariaDB 10.0 stable and its XtraDB drop-in replacement for InnoDB that it shares with Percona 5.6.

[totten]

FWIW: I can't confirm this is true, but this issue suggests a 5.6 incompatibility: https://issues.civicrm.org/jira/browse/CRM-15431

[JoeMurray]

I am pretty sure that is a bug related to code incorrectly assuming connection will always be over mysql rather than mysqli. So it is not specific to v. 5.6.