Revert "[11.x] Bump supported database versions"

[GrahamCampbell]

Reverts #9017. It is much too soon to do this, and this will only stop people upgrading to Laravel 11. The effort for us to continue supporting these older databases is very low and just because their OSS versions are EOL, it doesn't mean there aren't OSs providing security backports or other support plans, etc.

---

Is there a good reason to not support postgres 9.6 on Laravel 10, too? Would we consider lowering the min version in the Laravel 10 docs for postgres back to 9.6?

[driesvints]

@GrahamCampbell Postgres 9.6 isn't supported by Postgres itself and thus we don't support it either: https://www.postgresql.org/support/versioning/

[driesvints]

Bit torn on not removing support for MySQL 5.7 in Laravel v11 because it doesn't seems sense to support something that won't get bug or security updates any longer. However, it might be too much of a hurdle for people to upgrade.

We can maybe deprecate in Laravel v11 and remove in Laravel v12?

[GrahamCampbell]

I would be in favour of that, not just for mysql, but for the other versions too, apart from sqlite. Why would we drop older versions of that, so aggressively?

[X-Coder264]

MySQL 5.7 was released in 2015 so we are talking about a 8 year old release and as such I don't see anything aggressive about dropping such an old version in a new major version of the framework (5.7 will still continue to work on Laravel 10). MySQL 8.0 was released in 2018 so people had half a decade to upgrade.

[driesvints]

@X-Coder264 it's just not as easy to upgrade database engines as it is with PHP components/frameworks. I can understand the sentiment to wait a bit longer and give a notice much in advance that this is coming.

[hafezdivandari]

Latest framework version always supports the latest PHP versions only, we always upgrade to the latest packages/dependencies on major versions, so following the same pattern we should also drop support for outdated databases, that is how we can move forward, add more features to the framework and remove obsolete ones just like what is happennig on laravel/framework#48864

Why should someone upgarde to PHP 8.3 and Laravel 11 but keeps using outdated Database like MySQL 5.7?

[GrahamCampbell]

Why should someone upgarde to PHP 8.3 and Laravel 11 but keeps using outdated Database like MySQL 5.7?

That is totally a thing. Upgrading from MySQL 5.7 to 8.0 is a huge undertaking, and buisnesses may prefer to pay for security backports rather than upgrade their database, but still want to have modern PHP code and track the latest version of Laravel.

[hafezdivandari]

You can still use MySQL 5.7 on Laravel 11 but it is not actively supported anymore.

The effort for us to continue supporting these older databases is very low

This is not true, please check the migration documentation to see how many extra sections we have to explain support on legacy databases and how much redundant code we kept on the core to make this happen.

[GrahamCampbell]

There is not that much code to keep around. I think it's just the rename column that's a pain in the ass, because we've gotta query to find the original column definition so we can retain it with.

[hafezdivandari]

I disagree, but as I said above, it is still possible to use MySQL 5.7 on Laravel 11 and use a workaround for renaming columns ($table->string('old_name')->renameTo('new_name')->change() instead of $table->renameColumn('old_name', 'new_name')).

Laravel is not the first framwork that drops support for MySQL 5.7, e.g Django did the same on its latest version: https://docs.djangoproject.com/en/4.2/releases/4.2/#dropped-support-for-mysql-5-7

[Jubeki]

I am also in Favour of Dropping MySQL 5.7, one of the reasons it the problem with the database collations for MySQL, which are also currently being discussed.

MySQL 8 supports a newer collation which helps with unicode characters, which are not supported with MySQL 5.7, which would not be possible to support going forward in the skeleton for example. (See laravel/framework#48455)

The following comment taken from laravel/laravel#6239 :

The project skeleton still uses the old utf8mb4_unicode_ci MySQL v5.x collation. This causes problems with things like emojis when using MySQL 8. utf8mb4_0900_ai_ci is the correct collation for MySQL v8.

From the MySQL v8 reference manual:

The default MySQL server character set and collation are utf8mb4 and utf8mb4_0900_ai_ci, > but you can specify character sets at the server, database, table, column, and string literal levels.

Example of a problem when using utf8mb4_unicode_ci with MySQL v8: > https://x.com/reinink/status/1265349317314969605?s=20

[GrahamCampbell]

Different supported collations is a week argument. We could just make the default skeleton use utf8mb4_0900_ai_ci, and if people wanna change it to utf8mb4_unicode_ci, they can.

[Jubeki]

Different supported collations is a week argument. We could just make the default skeleton use utf8mb4_0900_ai_ci, and if people wanna change it to utf8mb4_unicode_ci, they can.

I think some/many people will then create an Laravel Framework Issue instead of searching a solution. There probably will also be multiple PR to the skeleton to change the collation.

(Probably not so many reports to the framework if we add an Error Solution to Ignition)

[deleugpn]

The fear of a few tickets being compared against an upgrade from MySQL 5.7 to 8.0 is not something I expected to read.

I have to side with Graham on this. I don't think the effort for Laravel to keep support for MySQL 5.7 is high, if there are facts to contradict this it would be good to lay them to make it clear why dropping support is preferred by the maintainers. MySQL 5.7 is not even cold yet and there's also database engines that were created as a fork of MySQL 5.7 that may not be out of support yet.

The comparison of database engine with PHP version is also invalid because PHP, Composer and Laravel itself are all tied together. Dropping support of older PHP version means Laravel own code can make use of newer PHP features. This isn't the same for database engines. One can argue that renaming column is one such example but Laravel already supports renaming column for years without having to drop support for the entire engine.

[hafezdivandari]

MySQL 5.7 is not even cold yet and there's also database engines that were created as a fork of MySQL 5.7 that may not be out of support yet.

MariaDB started as a fork of MySQL, we support MariaDB 10.10+ on Laravel 10 that replicates MySQL 8.0. Check here.

One can argue that renaming column is one such example but Laravel already supports renaming column for years without having to drop support for the entire engine.

There is a NATIVE workaround for renaming column on MySQL 5.7 as of Laravel 10, that I mentioned above (using change column instead of rename column)

Dropping support of older PHP version means Laravel own code can make use of newer PHP features. This isn't the same for database engines.

That is exactly the same for database engines. Although MySQL 5.7 will be still usable on Laravel 11, it is not necessary to have test flows for 5.7 on the next Laravel major version. As we don't have tests for PostgreSQL 9.6 or other outdated DBs as well. The discussion started from this PR: laravel/framework#48864 (comment)

[deleugpn]

Your reply makes it sound like you only care about MariaDB fork of MySQL. However, I'm aware of Laravel dedicated support for MariaDB.

AWS RDS still supports MySQL 5.7 until end of February 2024 and will also allow customers to sign up for extended support. https://repost.aws/articles/ARWm1Gv0vJTIKCblhWhPXjWg/announcement-amazon-rds-for-mysql-5-7-will-reach-end-of-standard-support-on-february-29-2024

AWS Aurora compatible with MySQL 5.7 is still supported.

PlanetScale is still compatible with MySQL 5.7 https://planetscale.com/docs/reference/mysql-compatibility

Percona Server still supports MySQL 5.7 https://www.percona.com/navigating-mysql-5-7-end-of-life

Oracle Cloud still supports MySQL 5.7 under Sustaining Support https://www.mysql.com/support/eol-notice.html

TiDB is a MySQL 5.7 compatible database still supported https://docs.pingcap.com/tidb/stable/mysql-compatibility

Google Cloud still supports MySQL 5.7 https://cloud.google.com/sql/docs/mysql/db-versions

Microsoft Azure supports MySQL 5.7 https://learn.microsoft.com/en-us/answers/questions/1323567/azure-mysql-support-for-mysql-v5-7-beyond-oracles

Yandex support MySQL 5.7 https://cloud.yandex.com/en/services/managed-mysql

I will not engage in discussing Postgres as I have no knowledge or expertise about it.

[hafezdivandari]

@deleugpn thank you for the list, but Laravel is not a "Cloud Service Provider". We may compare this to other "Web Frameworks" for example:

• Ruby on Rails has partial support for MySQL 5.7 which doesn't include renaming columns
• Django 4.2 has dropped support for MySQL 5.7

We can investigate other frameworks and complete this list (I didn't want to spend much time on this) if it helps. But the point is it's not necessary to have workarounds for features that legacy databases doesn't support on the latest Laravel version anymore.

[deleugpn]

I'm not asking Laravel to run a managed MySQL 5.7 as a Cloud Service Provider, so that's quite a moot point. What I'm pointing out is that MySQL 5.7 is not as legacy as its being expressed. It's the biggest database platform the world has ever seen and there's tons of derivative work from MySQL 5.7 still actively supported, as well as MySQL 5.7 itself under certain conditions. How much Laravel benefits from dropping 5.7 isn't something that is clear and is the foundation of questioning the decision to drop support for it. Running the latest version of Laravel with a supported MySQL 5.7 database is something that won't disappear overnight as database migrations are a major task and Laravel is in a position to reconsider its previous decision without much of a hassle.

[Jubeki]

Maybe its time to revisit this PR @GrahamCampbell because it seems Laravel 11 will continue to Support MySQL 5.7 (not sure about all the other PostgreSQL versions).

The only thing would be the required Sqlite Version constraint which should be higher. (Based on laravel/framework#48864)