Understanding the New Cadence: Quarterly CPUs, Targeted CSPUs, and Transitioning to Calendar Versioning
MySQL is updating its release model to make releases easier to understand, plan for, and follow:
- Clearer version numbers that show when a release line begins
- More predictable maintenance planning around quarterly releases, CPUs, and, when needed, targeted security updates, CSPUs
- Clearer release cadence signals for the MySQL community and ecosystem
The goal is not simply to change the number on a release. The goal is to give users, DBAs, developers, Linux distributions, cloud platforms, and ecosystem partners a clearer way to answer a few practical questions:
Which release line am I on? How long will it be supported? When should I expect routine updates? What happens if an urgent security update is needed between regular releases? And where should I look for authoritative information?
This updated model is built around two ideas: Calendar Versioning, which makes release-line timing clearer, and two production-grade release tracks: Innovation and Long-Term Support.
A quick note on CPU and CSPU
CPU means Critical Patch Update: Oracle’s regular quarterly security patching cycle. For MySQL, CPU fixes are delivered through normal MySQL release packages, so those packages may include more than security fixes.
- In an LTS release, a quarterly package update may include security fixes and bug fixes while preserving stability.
- In an Innovation release, it may include security fixes, bug fixes, and new features.
CSPU means Critical Security Patch Update: a targeted security update that can be released between quarterly CPUs when needed.
Together, CPU and CSPU provide a regular quarterly security rhythm through CPU, plus a focused path for urgent security fixes through CSPU. Each CPU/CSPU is published with advisory information. The location the advisory information is posted on, depends on the edition of MySQL being used.
Moving to Calendar Versioning (YY.M)
Historically, MySQL version numbers followed a traditional sequential model (e.g., MySQL 8.0 to 8.4 to 9.7). Moving forward, MySQL is transitioning to a calendar-based format.
This shift was shaped in part by feedback from our active community, including MySQL Rockstars and Oracle ACEs. Their insights helped validate our direction while refining an important detail: using a month-based YY.M format instead of a quarter-based format. This gives each release number immediate practical meaning.
Under the YY.M format:
- YY represents the last two digits of the year.
- M represents the release month, written without a leading zero (January is
1, April is4, July is7, October is10).
Both Innovation and LTS releases will follow this format. However, once a specific release is designated as an LTS line, that YY.M prefix remains constant for the rest of its support lifecycle.
Upcoming Cadence Examples:
- 26.7 – July 2026 Innovation release
- 26.10 – October 2026 Innovation release
- 27.1 – January 2027 Innovation release
- 27.4 – April 2027 Innovation release
- 27.7 – July 2027 Innovation release
- 27.10 – October 2027 Innovation release
- 28.1 – January 2028 Innovation release
- 28.4 – April 2028 LTS release
- 28.7 – July 2028 Innovation release
Innovation and LTS remain separate, production-grade tracks
The updated version format works across both MySQL Innovation and MySQL Long-Term Support releases.
Innovation releases
For users who want the latest capabilities, improvements, and fixes on a faster cadence. These releases are a good fit for teams that can test and upgrade regularly and want to evaluate new functionality earlier.
Under the updated model, scheduled Innovation releases use the current calendar year and release month:
26.7.0 → 26.10.0 → 27.1.0
Long-Term Support (LTS) Releases
For users who prioritize absolute stability, longer maintenance windows, and minimal behavior-change risk. LTS releases remain the natural standardization target for many production deployments.
For LTS, the first release uses the current YY.M.0 value, and then that YY.M value stays fixed for the full LTS lifecycle. For example:
28.4.0 → 28.4.X → 28.4.Y → 28.4.Z
This ensures an LTS line retains the identity of exactly when it started. Even when the calendar year changes, the version line remains anchored to its origin, making lifecycle tracking effortless.
Managing the Maintenance Cadence: Quarterly & As-Needed
The quarterly release remains your primary cadence for deployment planning. It provides a predictable, steady rhythm for testing, certification, and internal upgrade cycles.
CSPUs, by contrast, are strictly as-needed. A CSPU should not be interpreted as a new monthly obligation. If a high-severity vulnerability requires a targeted patch between quarters, a CSPU will be issued for the specific affected products and documented in the applicable advisory. Both Innovation and LTS lines can receive CSPUs if the situation warrants it.
| Release line | Track | Quarterly release line examples | What to notice |
| MySQL 8.4 | LTS | 8.4.9 | Existing LTS line continues on its established release line. |
| MySQL 9.7 | LTS | 9.7.0 | Existing LTS line continues on its established release line. |
| MySQL Innovation | Innovation | 26.7.0, 26.10.0, 27.1.0, …28.1.0 | Innovation advances by release year and month. |
| Future MySQL LTS | LTS | 28.4.0 | Future LTS keeps its starting YY.M identity for the life of that LTS line. |
Note: While quarterly maintenance releases are aligned with Oracle’s CPU cycle, they are not limited to security fixes; they include bug fixes for LTS, and bug fixes plus new features for Innovation lines.
What this means for upgrade planning
For users, the updated model should make release planning more transparent.
When you see an Innovation release such as 26.10.0, you know it is the scheduled Innovation release for October 2026. When you see an LTS release such as 28.4.10, you know it is still part of the LTS line that began in April 2028.
That clarity matters for automation as much as it matters for people. CI systems, packaging pipelines, deployment tooling, documentation, support processes, and internal upgrade policies all benefit from version numbers that are predictable, ordered, and meaningful.
Where to Track Release and Security Information
While the versioning model is changing to be more intuitive, official documentation remains your single source of truth for final implementation details.
- MySQL Community Edition: Security advisory info is published on the MySQL Community Vulnerability Advisories page, detailing severity, affected components, and impacted versions.
- MySQL Enterprise Edition & Oracle Offerings: Users should refer to Oracle’s Critical Patch Updates, Critical Security Patch Updates, Security Alerts and Bulletins page. This serves as the primary location for CPU/CSPU advisories and CVE-to-advisory mapping.
The Takeaway
The updated MySQL release model is designed to make our software easier to consume, starting with the forthcoming Innovation release this July.
Calendar Versioning clearly anchors the timeline of a release line. Innovation and LTS tracks continue to serve distinct adoption strategies. Quarterly releases remain your core planning target, backed by a regular CPU cycle and protected by an agile, as-needed CSPU pathway for urgent security needs.
The result is a model that is easier to read, easier to automate, and easier to plan around.
As always, thank you for being a part of the MySQL community!
And, as always, thank you for using MySQL!
References and official resources