MySQL ships its first calendar-versioned release

Oracle shipped MySQL 26.7.0 on July 28, 2026 — the first release under the calendar-versioning scheme it announced on June 16. The number is a date. Under the new YY.M format, YY is the last two digits of the year and M is the release month written without a leading zero, so 26.7 is the July 2026 release, 26.10 is October's, and 27.1 is January 2027's. Nothing was skipped between 9.7 and 26.7; the version number simply stopped encoding a position in a lineage and started encoding a ship date.

The release notes make the change official — “MySQL Server now uses calendar-based versioning for releases after the 9.7 LTS series” — and hand the ecosystem a way to find the lineage the version string no longer carries. mysql_version.h gains MYSQL_PREVIOUS_LTS_VERSION, which reads “9.7.0” in this build, and its numeric twin MYSQL_PREVIOUS_LTS_VERSION_ID, 90700, so build-time checks can still reason about upgrade and downgrade paths. (WL #17310)

26.7.0 is generally available, not a preview. It is the default selection on the MySQL Community Server downloads page, sitting above 9.7.2 LTS, 8.4.11 LTS and 8.0.46. An Early Access build of 26.7 did exist — Oracle announced one on July 3 and distributed it from labs.mysql.com — but that stage closed when 26.7.0 shipped. What GA does not mean here is long-term support: 26.7 is an Innovation release, maintained only until the next quarterly drop. The production answer is therefore unchanged. 9.7 LTS is the number to standardize on, its 9.7.2 patch landed the same day as 26.7.0, and 8.4 LTS is still supported.

The contents are substantial. The headline item is the Change Stream Applier, a new replica SQL applier selected per channel with APPLIER_VERSION = 2 and configurable from 1 to 1,024 worker threads per channel, which separates apply progress from commit ordering so a worker blocked on a dependency can pick up another ready transaction instead of idling (WL #10500). Alongside it: post-quantum key exchange for TLS 1.3 when MySQL is built against OpenSSL 3.5 or later, with hybrid classical/PQC groups preferred for interoperability and a new force_pqc family of variables to require them (WL #17245); the Thread Pool plugin, previously Enterprise-only, arriving in Community Edition (WL #17296); and a Group Replication default flip from the XCOM communication stack to MYSQL, which is not an online change and requires stopping every member of a running group to migrate (WL #15709).

The release model around the numbering is less dramatic than the numbering suggests. Innovation and LTS remain two separate production-grade tracks and both use YY.M going forward, but an LTS keeps its starting YY.M for its entire lifecycle — which is why the next LTS is 28.4, April 2028, and its patches will be 28.4.1, 28.4.2 and so on. The existing 8.4 and 9.7 LTS lines keep the numbers they already have. Quarterly releases ride Oracle's Critical Patch Update cycle, with an as-needed Critical Security Patch Update available between quarters for urgent fixes.

What actually changes for operators today is smaller and more durable than the feature list. Version comparators, container tags pinned to a major, Ansible and Terraform version guards, and internal upgrade policies written against “9.x” all need to learn that 26.7 is newer than 9.7 and is not MySQL 26. I track the full release history — every major since 1995, with support state and EOL dates — on the MySQL versions page.