mariadb*: add deprecation information

[samford]

• Have you followed the guidelines for contributing?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install <formula>)?

---

In researching why 10.1 releases of mariadb were removed from the first-party downloads page, I noticed that it had been recently deprecated as of 2020-10. As such, I added the deprecation information and removed the livecheck block (so it's appropriately skipped).

The deprecation dates are mentioned on each major/minor release's "Changes and Improvements in MariaDB" page, so I also added deprecation information for the other versioned mariadb formulae.

Currently the mariadb formula uses 10.5, which has a deprecation date of 2025-06 but I wasn't sure if we wanted to add this to the formula. On the one hand, when 10.6 is released and mariadb.rb is copied as mariadb@10.5.rb, it would already have the correct deprecation date. On the other hand, the deprecation date in the mariadb formula would need to be kept up to date with the current major/minor release (or commented out until the formula is versioned).

If we think that the mariadb formula should also have a deprecation date (for the former reason), then I'll update this PR accordingly.

[carlocab]

In case you get weird CI errors (see last few posts): #66450

[carlocab]

I'm wondering:

Maybe it makes sense to do the same as with Python, where there is no mariadb.rb, only mariadb@x.x.rbs. Then mariadb can be a symlink to the latest mariadb formula.

That might simplify maintaining deprecation dates?

[sharris40]

All these test failures look like transient network errors.

RE the failures in #66450, those seem to be caused by different forks of MySQL being tested in the same run. Uninstalling a database server doesn’t remove the database itself by design, and all the MySQL forks store the database in var/mysql. When you change forks, you end up trying to use an incompatible database. Those failures don’t appear in this test run because we’re testing different versions of the same fork.

IMO, we should be using var/mariadb for the data files instead of var/mysql, with some means to migrate data files over automatically. I’m not an expert in MySQL, so there might be different problems with doing that.

[bayandin]

Maybe it makes sense to do the same as with Python, where there is no mariadb.rb, only mariadb@x.x.rbs. Then mariadb can be a symlink to the latest mariadb formula.

It's better not to do it if possible. We had to make it for python because there are too many dependents which we weren't able to migrate at once.

[fxcoudert]

This is fine, but it needs to be one commit per formula

[samford]

This is fine, but it needs to be one commit per formula

I've clearly spent too much time working on single-commit, squash-and-merge PRs lately 🤦

I've rebased and separated this into individual commits. For what it's worth, the only reason why I omitted the CI-syntax-only label for this initially was because I had been told previously that we shouldn't use it for deprecation PRs (though I'm not sure of the reasoning behind that).