Oracle Revamps MySQL Release Model — Adopting Calendar Versioning
- Apple’s Native Linux Container Tool Has Arrived — But Can It Really Replace Docker?
- 60% of MD5 Password Hashes Can Be Cracked in Under an Hour with a Single GPU
- Dirty Frag: Root Access on Every Major Linux Distribution — No Patch, No Warning
- Proton Mail: Data Transferred to FBI Again!
- How Close Are Quantum Computers to Breaking RSA-2048?
- What is the best alternative to Microsoft Office?
Oracle Revamps MySQL Release Model — Adopting Calendar Versioning
Oracle announced a significant overhaul of the MySQL release model on June 16, 2026, moving from traditional sequential versioning to Calendar Versioning — a format that encodes the year and month of release directly into the version number.
Why the Change?
Under the previous system introduced in July 2023, MySQL versions followed a sequential numbering scheme — 8.0, 8.4, 9.0, 9.7, and so on — with certain mature versions designated as Long-Term Support (LTS). The problem: numbers like “8.4” or “9.7” offered no immediate signal about when a release line began or how long it would be maintained, complicating upgrade planning for DBAs, CI systems, packaging pipelines, and cloud platforms alike.
Oracle also noted the change was shaped in part by community feedback from MySQL Rockstars and Oracle ACEs, whose input led to one key refinement: using a month-based format rather than a quarter-based one, giving each release number more precise meaning.
The New Format: YY.M
Going forward, MySQL version numbers will follow a YY.M format, where YY is the last two digits of the year and M is the release month without a leading zero. January = 1, April = 4, July = 7, October = 10.
The new model will take effect starting with the next Innovation release, scheduled for July 2026 (version 26.7.0). The existing MySQL 8.4 and MySQL 9.7 LTS releases are unaffected and will continue under their established versioning schemes.
Two Tracks: Innovation and LTS
Both release tracks continue under the updated model, each serving distinct user needs:
| Track | For | Cadence | Version pattern |
|---|---|---|---|
| Innovation | Teams wanting the latest features and improvements quickly | Quarterly | YY.M advances each quarter — e.g., 26.7.0 → 26.10.0 → 27.1.0 |
| LTS | Production environments that prioritize stability and long maintenance windows | Approx. every ~2 years | YY.M prefix stays fixed for the full lifecycle — e.g., 28.4.0 → 28.4.1 → 28.4.2 |
A key design decision for LTS releases: once a release line is designated LTS, its YY.M prefix is frozen for the entire support period. So the April 2028 LTS line will produce versions 28.4.0, 28.4.1, 28.4.2, and so on — even as years pass — making the release origin immediately recognizable regardless of the patch level.
Security Update Rhythm: CPU and CSPU
The announcement also reorganized MySQL’s security update cadence around two mechanisms:
Oracle’s regular quarterly security patch cycle. In LTS releases, CPU packages include security and bug fixes. In Innovation releases, they also include new features.
A targeted emergency security update issued between quarters only when a serious vulnerability is found. Available to both Innovation and LTS lines as needed — not on a fixed schedule.
Security advisory information will be published in two locations depending on edition: the MySQL Community Vulnerability Advisories page for Community Edition, and Oracle’s Critical Patch Updates and Security Alerts page for Enterprise Edition and Oracle offerings.
What It Means for Upgrade Planning
The practical upshot is straightforward: a version number like 26.10.0 immediately tells you it’s the October 2026 Innovation release. A version like 28.4.10 tells you it’s still part of the LTS line that launched in April 2028. That clarity benefits not just human operators but also automated tooling — CI pipelines, packaging systems, deployment scripts, and internal upgrade policies.
Existing MySQL 8.4 and 9.7 users are unaffected. Both remain on their existing LTS release models with no changes to their versioning or support timelines.
