At a recent discussion with MySQL ACEs and Rockstars, we were asked a fair question: If a bug is fixed in one supported MySQL LTS series, why isn’t it always fixed in another?
A quick refresher: LTS means Long-Term Support. Within an LTS series, MySQL aims to keep the feature set and data format stable while delivering bug and security fixes. That stability supports upgrade, downgrade, and clone options within the series. Innovation releases can introduce new features and behavior changes; when a new LTS release is established, the Innovation cycle continues.
MySQL 8.4 and MySQL 9.7 are both LTS series. That does not mean every code change will be identical across them.
What LTS maintenance includes
Quarterly MySQL maintenance releases can include security and nonsecurity bug fixes. They give users a regular way to pick up fixes within their chosen LTS series, but a fix appearing in one series does not automatically mean the same change belongs in every other series. blogs.oracle.com
Why fixes can differ between LTS series
A fix listed in one series’ release notes does not, by itself, tell us whether the same issue affects another series. If it does, the relevant code or behavior may still differ. A change that solves a problem can also affect applications that depend on established behavior. Those effects matter when maintaining an LTS release.
A recent example makes that tradeoff more concrete.
Case study: An InnoDB fix and application compatibility
An InnoDB fix improved row-size calculations to prevent a potential deadlock. It also made validation for some CREATE TABLE and ALTER TABLE statements stricter. SQL that had worked in earlier MySQL 8.4 releases could now fail with a “Row size too large” error. A software vendor with many customer installations was among those affected, along with other customers. The regression was reported publicly as Bug #120323. bugs.mysql.com
Engineering looked for a way to address both problems. In MySQL 8.4.11, the calculation needed to prevent the deadlock remained, while the earlier validation behavior was restored for most DDL operations. Some operations still require the stricter check. The 8.4.11 release notes describe the resolution under Bug #39249507 and reference the original deadlock fix, Bug #39129182. dev.mysql.com
Another affected customer needed a customer-specific build with this fix for its platform. After the customer tested and validated the fix, we included the compatibility change in the standard MySQL 8.4.11 release.
This case shows why the answer is sometimes more nuanced than “backport the fix” or “leave it out.” We needed to preserve the deadlock protection and address the impact on applications already running on an LTS series.
Where security updates fit
Oracle’s quarterly Critical Patch Update cycle is the main cadence for MySQL maintenance releases, which can include nonsecurity bug fixes. Critical Security Patch Updates provide an as-needed path for targeted critical security or stability issues between quarterly releases. That separate path does not decide how an ordinary bug fix should be handled across LTS series. blogs.oracle.com
How to raise a specific case
If a fix appears in one MySQL release but not in the LTS series you run, check the release notes for your series and share the bug number, your MySQL Server version, and the impact you’re seeing. A reproducible example is especially helpful.
Continue the public conversation in MySQL Community GitHub Discussions, or raise the question through your support channel. If you’ve found a new bug, report it in the MySQL Bugs database and link the report in the discussion.
We welcome concrete examples. They give us a better starting point for answering why a particular fix differs between releases.
As always, thank you for using MySQL!