mariadb: Use accurate end-of-life dates #258262
Conversation
github-actions
bot
added
automerge-skip
| # > Critical security fixes will be provided as source code releases only and | ||
| # > on a best effort basis for 2 additional years beyond Community maintenance | ||
| # > LTS level |
There was a problem hiding this comment.
I don't think this is the reason to keep 2 more years, upstream already specified the date of EOL.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
"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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Will they also still tag releases in the source until then?
| # From https://mariadb.org/about/#maintenance-policy: | ||
| # > For releases up to MariaDB 11.4, the binaries are released for 5 years | ||
| # > after the GA date (29 May 2024) |
There was a problem hiding this comment.
Not much differ, the original is still fine.
daeho-ro
added
the
CI-syntax-only
ottok
force-pushed
the
mariadb-eol-dates
branch
from
7c88f3e to
a4961dd
Compare
github-actions
bot
removed
the
automerge-skip
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 the updates in this commit and the two preceding it all current LTS versions of MariaDB have correct EOL dates on Homebrew and the Formulaes helpful comments to make the upstream policy clear for maintainers.
ottok
force-pushed
the
mariadb-eol-dates
branch
from
a4961dd to
1b79939
Compare
| # See: https://mariadb.org/about/#maintenance-policy | ||
| deprecate! date: "2026-07-06", because: :unsupported |
There was a problem hiding this comment.
Please also add a disable! date for when the software is really EOL.
| # > Critical security fixes will be provided as source code releases only and | ||
| # > on a best effort basis for 2 additional years beyond Community maintenance | ||
| # > LTS level |
There was a problem hiding this comment.
"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.
4 participants
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.
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.