MySQL CPU and CSPU Versioning for More Frequent Security Updates

Oracle plans to move MySQL security updates toward a monthly cadence, supplementing the current quarterly Critical Patch Update (CPU) schedule.

These monthly Critical Security Patch Update (CSPU) releases will be issued only when needed to address critical security or stability issues; they are not a fixed monthly release commitment.

These CSPU releases will focus on critical security and stability fixes rather than new features. Organizations should prepare to evaluate and accelerate their MySQL patching, testing, release, and deployment processes to maintain a current security baseline.

In the previous post, we introduced MySQL’s move to a more predictable release model, using calendar versions, LTS releases, Innovation releases, and regular CPU and CSPU release intervals.

The remaining detail was how version numbers distinguish a regular quarterly CPU release from a CSPU release issued between quarterly releases. That format is now finalized.

The version format

For new calendar-versioned MySQL releases, CPUs use three positions and CSPUs add a fourth:

The month does not include a leading zero: July is 7, October is 10, and January is 1.

The rule is simple: a CPU uses three positions; a CSPU adds a fourth position, beginning at .1. For Innovation releases, the third position remains permanently 0.

LTS release numbering

For an LTS release, the first two positions identify the release line. The third position advances with each Quarterly Maintenance Package. If CSPUs are needed before the next quarterly release, they use the fourth position; the next quarterly package increments the third position and returns to the three-position format.

The same structure applies to future calendar-versioned LTS lines. For example, the planned April 2028 LTS line starts at 28.4.0. CSPUs, if needed, would be 28.4.0.1 and 28.4.0.2; the next CPU would be 28.4.1.

Innovation release numbering

Each quarterly Innovation release starts a new calendar-versioned release line. Its third position is permanently 0; the next quarterly Innovation release changes the calendar portion rather than incrementing that third position.

If CSPUs are needed for the 26.7 line, they are 26.7.0.1, 26.7.0.2, and so on. The next quarterly Innovation CPU is 26.10.0—not 26.7.1.

CSPU numbers are assigned sequentially for the applicable release line. If one product uses a CSPU version, the next CSPU for another product on that line uses the next available C value. For example, if Shell is released as 27.1.0.1, a later Server CSPU on the same line would be 27.1.0.2.

Microsoft MSI package versions

These are MySQL product versions. Microsoft MSI packages use three numeric positions, so they combine MySQL’s Pand C values into the third MSI position:

MSI third position = 100 × P + C

For a CPU, C is treated as 0 for this calculation. For Innovation releases, P is permanently 0.

This MSI-specific representation does not change the MySQL product version; it only describes how that version is represented in Microsoft MSI package metadata.

Summary

Security vulnerability packages are not automatic. When one is needed, it adds a fourth position beginning at 1. The next LTS CPU increments P; the next Innovation CPU begins a new calendar line and retains P = 0.

Looking ahead

More frequent security updates give MySQL users a clearer path to maintaining a current security baseline. The CPU and CSPU versioning model makes it straightforward to identify the quarterly maintenance level and any intervening security update.

We encourage organizations to review their patching, testing, release, and deployment processes so they can evaluate and apply these updates promptly when needed.

As always, thank you for using MySQL!