[11.x] [policy] Require MySQL 8.0 and MariaDB 10.6

Adding info about Debian.

@effulgentsia the answer to the 'why not MySQL 8 and MariaDB 10.3' comment is in the paragraph directly before the sentence you quoted:

So... both will be EOL during Drupal 10's release cycle, but MariaDB will be EOL first. Therefore if we have to support MariaDB 10.3 due to distros, I can't see a reason to drop MySQL 5.7 quicker when it's going to be supported six months longer.

i.e. it was about distro lifecycles, not features. And then the comment about the InnoDB memcached plugin was that it wasn't a feature we particularly need in core (compared to say JSON support where we've been actively trying to get into a position where we can use it), so not a compelling reason to raise the constraint.

edit: i had a quick look, and it looks like the InnoDB plugin is already deprecated, so even less of reason: https://dev.mysql.com/doc/refman/8.0/en/innodb-memcached.html

So, one could make the argument that 10.5 is a reasonable minimum because it's available in all of the major distros (for Ubuntu sites can upgrade to 22.04 and for RHEL sites can either upgrade to RHEL 9 or if on RHEL 8 then they can use the non-full-life application stream).

I think this is a good argument. Ubuntu 22.04 has already been out for nearly a year.

if there aren't compelling 10.4 or 10.5 features that we want to use, I think it would be better to set the minimum to 10.3, for maximum distro compatibility.

Even though this seemed the other way around for 10.0, if it's the case that 10.3 is in LTS versions of distros and MySQL 5.7 isn't, then this seems OK, but... I haven't looked at the 10.4 or 10.5 feature sets.

I think it makes sense to be aggressive for D11 (i.e., require newer DB versions) since D10 will ideally be around for awhile.

Can we add the support timeframes for the distro versions to the IS? They're not easy to scan at present and not immediately obvious at the linked references either.

Meantime Mysql 8.1 is out and Oracle announced changes in release cycle

I'm ++ to set 8.0 looking at https://www.mysql.com/support/supportedplatforms/database.html

@xjm I've added the release dates for the distros (debian, ubuntu, RHEL) to the issue summary.

Also added the EOL date for Ubuntu 20.0.4 since that is the only version we already had listed which doesn't support all the versions we'd be requiring - it's April 2025, so there will be very little crossover between D11 anyway, 5-10 months.

I think in general we're mainly interested in when they added support for the versions we require, more than how long they'll support the previous version of the distro (or the version that will run our minimums), also EOL dates are complicated because there's often a phase out/shift to commercial rather than a hard stop.

Update:
https://mariadb.org/download/?t=mariadb&p=mariadb&r=10.11.6&os=Linux&cpu...

MariaDB now has more frequent releases, and five year support LTS minors every so often.

The two, active, LTS minors are 10.6 and 10.11

I therefore think given we already decided to go to MariaDB 10.5 here, we should consider bumping that to 10.6 since that's the version that hosting is actually likely to want to run, distros provide etc. and talk about whether to consider going to 10.11 or not (released early this year).

MySQL's next LTS release will be 8.4 (see @andypost's link above), and that looks like it won't be out before Drupal 11.0, so for me that means we pretty firmly should pick MySQL 8.0 as a minimum.

Debian bookworm (stable) now includes MariaDB 10.11

No change for Ubuntu LTS (22) or RHEL 9.

Updated for the MariaDB release/support cycles too now.

If we want to support RHEL 9, we have to support MariaDB 10.5, otherwise 10.6 looks realistic. MariaDB 10.5 goes out of official support in 2025, so Drupal 11 sites would get one year on it (if they're not on an LTS distro that does its own security support).

What's your definition of "active, LTS" and why does it include 10.6, but not 10.5? From https://mariadb.org/download:

It's because I mis-read the MariaDB post the first time...

But also I think in terms of the Drupal 11 cycle a 2025 EOL that is potentially less than a year after Drupal 11.0.0 is not very active or LTS in context, i.e. it could be out of support before 11.0.x if we end up using the December window.

I think this is ready for review now.

MySQL 8.2 was released in Oct 2023 and the new Oracle release cycle promise quarterly releases. So in case of December release window, there is a chance that there will be the next LTS already available.

But I know this is not 100% and we cannot predict it (together with the Drupal 11 release window), so I think MySQL 8.0 is a way to go.

Tagging the same as the php8.3 ticket just in case

But sounds like the consensus is mysql 8.0 is preferred.

I think we need to decide between MariaDB 10.5 or 10.6 still. In the past we have based decisions on RHEL as the slowest-but-still-supported distro, but since their active hostility to downstream distros this year, and the much longer support cycle for Drupal 10, I'm not convinced that should be the determining factor any more. If we want to try to keep Drupal sites on officially supported versions of releases, then 10.6 is the better target since if a Drupal 10 site goes to 10.6, it'll be supported until around Drupal 10's EOL, making it a good bridge version between the two (in the same way that PHP 8.3 is).

Updated the issue summary again and leaving needs review.

MySQL 8.2 has been released on 25th October 2023.

If it would be fully up to me we would go for MySQL 8.2 and MariaDB 10.11. Both are the newest versions for both databases. MariaDB 10.6 is by the time we release D11 already 3 years old and MySQL 8.0 is by than 6 years old. If somebody does not have hosting that is compatible with MariaDB 10.11 or MySQL 8.2, they should keep using D10. D10 will be supported until at least the summer of 2026.

Re #23: Yes, but according to this: https://blogs.oracle.com/mysql/post/introducing-mysql-innovation-and-lon... , 8.2 is not a LTS version, so I am not sure if it would have any benefit to require that.

In case there will be the next LTS (probably MySQL 8.4) available by 11.x beta, that would probably make sense.

@poker10 Thanks you for the info. You are right a LTS would be preferable. MySQL 8.0 with a EOL of April 2026, would mean that it would be EOL before the release of D12. Both are not great options.

Updating the issue title to indicate that MariaDB 10.6 is in contention.

Maybe I am missing the point in why distributions are so important. In #3330874: [11.x] [policy] Require PHP 8.3 for Drupal 11 we set the minimum version for PHP to 8.3 in spite of no distribution supportion PHP 8.3. Yet, for MySQL and MariaDB it is somehow the deciding factor. We are now in a situation were every new major version of Drupal has an older major Drupal version that has full support. When D11 is released you do not have to migrate anytime soon. For at least 2 years after the release of D11 you can still use D10 and have full support. This gives us the possibility to set the minimum requirements for MySQL and MariaDB as high as possible. The newer versions of MySQL and MariaDB have an improved performance and some new features. When people do a performance comparison between D10 with MySQL 5.7 and D11 with MySQL 8.2 the performance improvement will be much better than with D11 on the oldest version of MySQL 8.0.

@daffie we've used the distributions as a basis essentially forever, it's only really PHP, and our PHP dependencies, which have caused the shift away from relying solely on distribution support.

Now that PHP has predictable release cycles and we have more PHP dependencies, it makes sense to follow those release cycles more than the distros - and we have 9.x and 10.x already to show that the distros catch up to new PHP versions quickly enough, and that supporting lower versions of PHP causes problems later. That makes requiring PHP 8.3 very easy.

With databases though, we don't have dependencies that will rely on minimum versions of those databases,we have at least four databases with their own independent release cycles, with varying levels of predictability and frequency. It's also much less clear how and when distros will keep up since even where the database release cycles are predictable they haven't been for very long.

The other consideration would be that for non-container hosting, it's easy enough to run multiple versions of PHP with php-fpm, but it's not as easy to run multiple versions of a database. So I do think it's harder with the database requirements.

I've added the Ubuntu Noble versions to the issue summary - MariaDB 10.11 and MySQL 8.0

@catch I know that we have used distribution as a basis essentially forever. Just like you have said. The big change for me is that we are now do a new major release with there being a previous major release that is almost the same as the new major version and the previous major release has 2 more years of full support. For me that is a big change. Lets agree that we have a different opinion. :)

However you are the release manager and let go with your opinion. We have little choice than to go with MySQL 8.0 as a minimum version. For MariaDB we have a couple of options:
- We have MariaDB 10.5 which is released with RHEL and has an EOL in 2025;
- We have MariaDB 10.6 which is not in RHEL and has an EOL in 2026;
- We have MariaDB 10.11 which is not in RHEL and has an EOL in 2028.

If we look at the distributions we should go with MariaDB 10.5. That version has an EOL in 2025, which is only 1 year after the release of D11. D11 will be supported by us until 2028.
If we do not take RHEL in account we can go with MariaDB 10.11. That version has an EOL in 2028, which is the same year as we offer support for D11.

@catch: I will let you make the choice for which the minimum version for MariaDB should be for D11. My preference would be MariaDB 10.11. If you however will select MariaDB 10.5, that is fine by me too.

@daffie just to clarify, it's not my opinion that we should rely on distribution support any more, or at least, I definitely don't think we should rely on it as much. It's also not solely my decision by any means.

I do think it's slightly harder to require database versions than PHP versions because there are well documented ways to run multiple PHP versions on non-container hosting which don't apply in the same way for databases. That makes me less confident here than with PHP 8.3.

Given Ubuntu and Debian will both have releases in 2024 with MariaDB 10.11, I do think that's viable, so adding to the issue summary/title.

Are we concerned, for example, that in 2027 or 2028 we'll still be supporting D11 and we might find a MariaDB 10.6 bug that doesn't exist in MySQL 8.0 and that MariaDB won't fix and Drupal's core mysql driver will find challenging to work around? This would be a reasonable benefit to setting 10.11 as our minimum, but do we have any prior experience of this actually happening with prior MariaDB EOL versions?

I don't think we have previous examples, but also the MariaDB release schedule has only existed since 10.6, which is since July 2021, so there is not enough time for it to have been in place, for us to know how it'll affect us.

MariaDB will only be supported until July 2026, so if we require that, we'll be supporting it for approximately two years longer than MariaDB does.

For PHP versions we (soft) drop support when they go out of support by PHP core, but we've never done that for a database version that I can remember.

If we end up setting MariaDB's minimum to 10.11, the next question to figure out would be when to start enforcing that in HEAD.

I would say right after 10.3.x branch is open we can update it in 11.x. According to https://www.drupal.org/about/core/policies/core-release-cycles/schedule we can have 11.0.0-beta1 in March 2024, which is definitely before Ubuntu 24.04. I also suspect folks on LTS versions of Ubuntu won't be updating to 24.04 the day it's released, possibly closer to the May 20 date for 11.0.0-rc1 or even more realistically closer to 11.0.0.

It looks like no one from Pantheon has commented on this issue.

/waves

I agree with @effulgentsia's perspective on looking at feature requirements more than super long support/distro lifecycles. Some sites just need to launch to support an event, and MariaDB 10.6 will remain a perfectly reasonable choice for projects like that; the EOL is still years out. If someone decides to run Drupal on an EOL DB version, then it's at least slightly unsupported as a stack in general -- and not by our doing, anyway.

Generally, reducing friction is good.

As for the Pantheon question, I don't know any ETA for next MariaDB version offerings. I can share that we're considering picking up GCP Cloud SQL as an option for running sites, which would offer actual MySQL, potentially more than one choice amongst the 5.7+ choices (which include an 8.0 offering). We would definitely offer MySQL 8.0 if we offer any Cloud SQL options.

I agree with the sentiment of #33/35. There doesn't seem to be any pressing reason, other than support timescales, to push us towards requiring newer versions of either MySQL or MariaDB. Other than JSON support I can't think of any database feature that we have required in recent history that has meant we have to increase minimum versions; as stated above in practice even though we raised the requirements for Drupal 10, older versions of database engines don't require any different code anyway.

Therefore if there is no technical requirement to do so, we should not aggressively increase our requirements and that MySQL 8.0 and MariaDB 10.6 are an OK compromise given that most users will likely already be using these versions. And it probably wouldn't even matter if we did nothing here and just left the baseline requirements where they are.

OK let's just go for MySQL 8.0 and MariaDB 10.6, I think that's a good balance. We can revisit again for Drupal 12 once the various support cycles have settled in.

Untagging for release manager review because three of us have commented now.

I have been following this discussion and I support the decision.

I have updated Database server requirements

Made an issue to make sure there is a testing environment for MariaDB 10.6. #3420973: Add MariaDB 10.6 to CI. And one to update core template, #3420974: Add testing wtih Maria DB 10.6.

The policy is agreed to and we have the follow ups.

Is there any reason you don't update INSTALL.txt as part of this issue? I find it confusing when the wiki is updated (like quietone just did - great), but the source code isn't. I normally like to point to INSTALL.txt if there is a discussion about requirements.

@hansfn: we want to set requirements early enough (see #3214954: [11.x] [meta] Set Drupal 11 platform and browser requirements at least six months before the release), however the 11.x branch is not yet open for development of 11.x. It is true that we need a dedicated issue to update the INSTALL.txt info once the branch is open for 11.x development. Can you help open an issue for that? Thanks!

Opened #3421175: Update INSTALL.txt and hook_requirements() etc. with remaining Drupal 11 platform requirements.

Shouldn't this have a change record? We can have a single change record for all the DB version requirements for D11.

Change record added.

The change record looks good to me.

I added a note about the 5.7 driver to the CR.