mariadb: Use accurate end-of-life dates

[ottok]

As MariaDB is built from sources on Homebrew, the actual end-of-life dates announced on Homebrew should reflect the date MariaDB is committed to publish updates as source code, which is further out than what they commit to regarding binaries.

With these updates all current LTS versions of MariaDB have correct EOL dates on Homebrew.

---

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?

This is the same change done in a uniform way to 3 formulaes. Technically this violates the rule of one PR per formulae, but it could also be justified that this update is "atomic" in a way as it is the same change. I can split this into 3 identical PRs if reviewers request it.

[daeho-ro]

I don't think this is the reason to keep 2 more years, upstream already specified the date of EOL.

[ottok]

Thanks for the review!

Upstream defined the date for EOL as 2030-06-04 for MariaDB 11.8, and that is the whole point why I submitted this PR. The date in Homebrew is currently wrong as the last binary release date was used, not the actual date for how long Homebrew, Linux distros and anyone else building from sources has.

[SMillerDev]

"best effort" doesn't really sound the same as "supported". But the deprecation date should probably be whenever they stop doing normal releases, with the disable! being this date when it is fully EOL.

[ottok]

In their vocabulary "supported" means when they publish binaries, which does not affect Homebrew. For Homebrew the relevant date is how long there will be updates in the source code, which is until 2030-06-04.

[SMillerDev]

Will they also still tag releases in the source until then?

[vuvova]

yes

[daeho-ro]

Not much differ, the original is still fine.

[SMillerDev]

Please also add a disable! date for when the software is really EOL.

[SMillerDev]

"best effort" doesn't really sound the same as "supported". But the deprecation date should probably be whenever they stop doing normal releases, with the disable! being this date when it is fully EOL.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[ottok]

Please keep this open a bit more until we get some another person to confirm that the 11.8 EOL for the purposes of Homebrew source imports is really 2030-06-04 as the references I provided were apparently not worded clearly enough.

[p-linnane]

The dates should match the Community column in https://mariadb.org/about/#maintenance-policy.

[vuvova]

The table in https://mariadb.org/about/#maintenance-policy is for binaries, the message above says MariaDB Community LTS binaries are released for 3 years after the GA. Sources will still be released, with bugfixing, tags, everything, for 5 years as now.

[p-linnane]

I'm aware. Our position as Homebrew maintainers is that the 'best effort' designation doesn't convey the kind of fully supported status we need to see in order to delay the deprecation.

[vuvova]

I'd think that everything a non-profit foundation is doing is kind of "best effort". But anyway, the phrasing was changed, now it's saying

Critical and security fixes will be provided in source code releases for 2 additional years beyond Community LTS binary release period

is it better?

[ottok]

Could you @stefanb please approve this? The commits document clearly why the dates are correct, and we even have an upstream developer confirming here that I read their EOL policy correctly. Thanks!

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[ottok]

The commits document clearly why the dates are correct, and we even have an upstream developer confirming it here.

Could somebody approve this? Thanks!

[SMillerDev]

I would still like to see a disable date added. And I'm not sure we should be extending the builds beyond what upstream will build.
Sure it'll still be technically supported, but if upstream doesn't want to provide builds I don't think we can say our builds are still supported.

[ottok]

MySQL formulas don't have 'disable' dates. Why are they now a requirement for MariaDB? Upstream does not provide any Mac builds at all to my knowledge. Homebrew uses upstream sources and thus the source maintenance policy, and should have same EOL dates as eg. Debian and Fedora have for MariaDB. This has already been explained several times, even with upstream chief architect commenting here.

[SMillerDev]

MySQL formulas don't have 'disable' dates.

Homebrew formula have disable dates to indicate when support from upstream ends. Because that is the moment Homebrew support 100% ends.

The upstream policy has been clarified. Now we as homebrew needs to decide how that maps to our depreciation policy

[p-linnane]

I'm in agreement with @SMillerDev. The deprecate!/disable! split exists for exactly this scenario: deprecate! at binary EOL, disable! when the source-only window closes. "Best effort" security fixes are not the same as fully supported, and extending the deprecation date would imply otherwise.

[cho-m]

Homebrew uses upstream sources and thus the source maintenance policy, and should have same EOL dates

In addition to previous explanations, I want to clarify that Homebrew deprecation date is based on multiple requirements, including but not limited to upstream EOL. So just because upstream has a longer support cycle does not mean Homebrew will.

For versioned formulae, requirements include everything listed at https://docs.brew.sh/Versions#acceptable-versioned-formulae

Looking at MariaDB LTS versions, it will likely be impacted by:

• No more than five versions of a formula (including the main one) will be supported at any given time, unless they are popular (e.g. have over 1000 analytics 90 days installs of usage). When removing formulae that violate this, we will aim to do so based on usage and support status rather than age.

If the release cadence and analytics remain the same, with MariaDB 15 on Q3 2028 will mean we only support:

1. mariadb - 15
2. mariadb@14 - 14.3
3. mariadb@13 - 13.3
4. mariadb@12 - 12.3
5. mariadb@11.x - either 11.4 or 11.8 based on support and popularity

So Q3 2028 will be deprecation date for either mariadb@11.4 or mariadb@11.8 (our official policy is actually direct removal but we often just let it get auto-removed via deprecation).

With MariaDB 16 on Q3 2029 this will then result in adding mariadb@15 and deprecating mariadb@11.x.

[cho-m]

Also some comments on disable date in current Homebrew.

---

MySQL formulas don't have 'disable' dates. Why are they now a requirement

Homebrew automatically applies a +1 year disable date. If you want a longer/shorted deprecation period, then you need to provide it via DSL.

The request for disable date is an extension on time frame, e.g. try adding deprecate! date: "2026-02-26", because: "is being tested" to mariadb:

❯ brew info mariadb | grep Deprecate
Deprecated because it is being tested! It will be disabled on 2027-02-26.

And then add a disable date of some arbitrary date like 2030-01-01:

❯ brew info mariadb | grep Deprecate
Deprecated because it is being tested! It will be disabled on 2030-01-01.

---

I would still like to see a disable date added.

Right now, we may not want to add uncommented disable dates because brew's handling of this is incomplete and will incorrectly consider a formula deprecated.

EDIT: Now fixed so can add disable date

• formula: handle future deprecation and disable dates brew#21644

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[ottok]

Homebrew uses upstream sources and thus the source maintenance policy, and should have same EOL dates

In addition to previous explanations, I want to clarify that Homebrew deprecation date is based on multiple requirements, including but not limited to upstream EOL. So just because upstream has a longer support cycle does not mean Homebrew will.

For versioned formulae, requirements include everything listed at https://docs.brew.sh/Versions#acceptable-versioned-formulae

Looking at MariaDB LTS versions, it will likely be impacted by:

• No more than five versions of a formula (including the main one) will be supported at any given time, unless they are popular (e.g. have over 1000 analytics 90 days installs of usage). When removing formulae that violate this, we will aim to do so based on usage and support status rather than age.

If the release cadence and analytics remain the same, with MariaDB 15 on Q3 2028 will mean we only support:

1. mariadb - 15
2. mariadb@14 - 14.3
3. mariadb@13 - 13.3
4. mariadb@12 - 12.3
5. mariadb@11.x - either 11.4 or 11.8 based on support and popularity

So Q3 2028 will be deprecation date for either mariadb@11.4 or mariadb@11.8 (our official policy is actually direct removal but we often just let it get auto-removed via deprecation).

With MariaDB 16 on Q3 2029 this will then result in adding mariadb@15 and deprecating mariadb@11.x.

If the above is the actual policy for Homebrew and the reason why MariaDB 11.8 availability in Homebrew is cut two years short, then remove the comment in the source code stating that the date is from MariaDB.org and replace it with explanation that it is a Homebrew policy date.