新しいリリースサイクルについて: 四半期ごとの CPU、ターゲットを絞った CSPU、カレンダー・バージョン への移行

MySQL は、より分かりやすく、計画、追跡しやすくするために、リリースモデルを更新します:

  • リリースラインの開始時期が明確になるバージョン番号
  • 四半期ごとのリリース、CPU、必要に応じて提供される対象限定のセキュリティ更新(CSPU) に基づく、より予測しやすいメンテナンス計画
  • MySQL コミュニティとエコシステムに向けた、より明確なリリースサイクルのシグナル

今回の目的は、単にリリース番号を変更することではありません。
ユーザー、DBA、開発者、Linux ディストリビューション、クラウド・プラットフォーム、エコシステム・パートナーが、次のような実務的な疑問に明確に答えられるようにすることです。

自分はどのリリースラインを使っているのか? そのリリースはどのくらいサポートされるのか?定期的な更新はいつ行われるか?定期リリースの間に緊急のセキュリティ更新が必要になった場合はどうなるのか?そして、信頼できる情報はどこで確認すべきなのか?

更新されたモデルは、リリースのタイミングを分かりやすくする カレンダー・バージョンと、本番運用に適した 2 つのリリーストラックである Innovation と Long-Term Support という 2 つの考え方を軸に構成されています。

CPU と CSPU についての簡単な補足

CPU は Critical Patch Update を意味し、Oracle が四半期ごとに実施する定期的なセキュリティ・パッチサイクルを指します。MySQL では、CPU による修正は通常の MySQL リリースパッケージを通じて提供されるため、それらのパッケージにはセキュリティ修正以外の修正も含まれる場合があります。

  • LTS リリースでは、四半期ごとのパッケージ更新に、安定性を維持しながらセキュリティ修正とバグ修正が含まれる場合があります。
  • Innovation リリースでは、セキュリティ修正、バグ修正、新機能が含まれる場合があります。

CSPU は Critical Security Patch Update を意味し、必要に応じて四半期ごとの CPU の間にリリースされる、対象を絞ったセキュリティ更新です。

CPU と CSPU を組み合わせることで、CPU による定期的な四半期ごとのセキュリティパッチ定期更新サイクル と、CSPU による緊急セキュリティ修正のための集中的な経路が提供されます。各 CPU/CSPU はアドバイザリ情報とともに公開されます。アドバイザリ情報が掲載される場所は、利用している MySQL のエディションによって異なります。

カレンダー・バージョン(YY.M) への移行

これまで MySQL のバージョン番号は、MySQL 8.0 から 8.4、9.7 へと続くような従来型の連番モデルに従っていました。今後、MySQL はカレンダーに基づく形式へ移行します。

この移行は、MySQL Rockstars や Oracle ACE を含む活発なコミュニティからのフィードバックにも一部基づいています。彼らの知見は、方向性の妥当性を確認するとともに、四半期ベースではなく月ベースの YY.M 形式を使用するという重要な詳細を洗練する助けになりました。これにより、各リリース番号がすぐに実務的な意味を持つようになります。

YY.M 形式では、次のようになります。

  • YY は年の下 2 桁を表します。
  • M はリリース月を表し、先頭のゼロなしで記述します。January は 1、April は 4、July は 7、October は 10 です。

Innovation リリースと LTS リリースの両方がこの形式に従います。ただし、特定のリリースが LTS ラインとして指定されると、その YY.M プレフィックスはサポートライフサイクル全体を通じて一定のままになります。

今後のリリーススケジュールの例:

  • 26.7 – 2026年7月 Innovation リリース
  • 26.10 – 2026年10月 Innovation リリース
  • 27.1 – 2027年1月 Innovation リリース
  • 27.4 – 2027年4月 Innovation リリース
  • 27.7 – 2027年7月 Innovation リリース
  • 27.10 – 2027年10月 Innovation リリース
  • 28.1 – 2028年1月 Innovation リリース
  • 28.42028年4月 LTS リリース
  • 28.7 – 2028年7月 Innovation リリース

Innovation と LTS は、引き続き異なるトラックとして提供されます

更新されたバージョン形式は、Innovation リリースと LTS リリースの両方に適用されます。

Innovation リリース

より短いサイクルで追加機能、改善機能、バグ修正を利用したいユーザー向けです。このリリースは、定期的にテストとアップグレードを行うことができ、新機能をいち早く評価したい場合に適しています。

更新されたモデルでは、予定されている Innovation リリースは現在の暦年とリリース月が使用されます:

26.7.0 → 26.10.0 → 27.1.0

LTS(Long-Term Support) リリース

絶対的な安定性、より長いメンテナンス期間、および動作変更リスクの最小化を重視するユーザー向けです。LTS リリースは、多くの本番運用環境において標準的に適用されています。

LTS では、最初のリリースが現在の YY.M.0 値を使用し、その後その YY.M 値が LTS ライフサイクル全体にわたって固定されます。

例:

28.4.0 → 28.4.X → 28.4.Y → 28.4.Z

これにより、LTS ラインは開始時期を正確に示す識別子を維持できます。暦年が変わっても、バージョンラインはその起点に固定されたままとなり、ライフサイクル追跡が容易になります。

メンテナンスの頻度管理: 四半期ごと、もしくは必要に応じて

四半期ごとのリリースは、デプロイ計画における標準的なリリース間隔です。テスト、認証、社内アップグレードサイクルのために、予測可能で安定したリズムを提供します。

一方、CSPU はあくまで必要時のみ提供されます。 CSPU を新しい毎月恒例の義務と解釈すべきではありません。四半期の間に、重大度の高い脆弱性に対して対象を絞ったパッチが必要となった場合、影響を受ける特定の製品に対してCSPUが発行され、該当するアドバイザリに記載されます。状況に応じて、Innovation ラインと LTS ラインの両方に対して CSPU が発行される可能性があります。

リリースライントラック四半期リリースラインの例注目点
MySQL 8.4LTS8.4.9既存の LTS ラインは、確立済みのリリースラインで継続します。
MySQL 9.7LTS9.7.0既存の LTS ラインは、確立済みのリリースラインで継続します。
MySQL InnovationInnovation26.7.0, 26.10.0, 27.1.0, …28.1.0Innovation はリリース年と月に沿って進みます。
Future MySQL LTSLTS28.4.0将来の LTS は、その LTS ラインの存続期間中、開始時の YY.M 識別子を保持します。

注: 四半期ごとのメンテナンスリリースは Oracle の CPU サイクルを反映していますが、セキュリティ修正だけに限定されるものではありません。LTS ではバグ修正が含まれ、Innovation ラインではバグ修正に加えて新機能も含まれます。

アップグレード計画にとっての意味

ユーザーにとって、更新されたモデルではリリース計画はより分かりやすくなります。

26.10.0 のような Innovation リリースを目にした場合、それが 2026年10月に予定されている Innovation リリースであることが分かります。28.4.10 のような LTS リリースの場合は、それが 2028年4月に開始された LTS ラインの一部であることが分かります。

この明確さは人にとって重要であるのと同じくらい、自動化の際にもとても重要です。CI システム、パッケージング・パイプライン、デプロイメント・ツール、ドキュメント、サポートプロセス、社内アップグレードポリシーはすべて、予測可能で、順序付けられ、意味のあるバージョン番号のメリットがあります。

リリースとセキュリティ情報の確認先

バージョン管理モデルはより直感的なものに変わりますが、最終的な実装の詳細については公式ドキュメントが唯一の信頼できる情報源です。

まとめ

更新された MySQL リリースモデルは、この 7 月に予定されている Innovation リリースから、ソフトウェアをより利用しやすくすることを目的としています。

カレンダー・バージョンは、リリースラインのタイムラインが明確に定義されます。Innovation と LTS のトラックは、それぞれ異なる導入戦略に対応します。四半期ごとのリリースは、定期的なCPUサイクルに支えられ、緊急のセキュリティニーズに対応するための機動的なCSPUの提供体制によって保護され、引き続き皆様の計画策定における中核的な目標となります。

その結果、理解しやすく、自動化しやすく、計画もたてやすいモデルが実現しました。

いつも MySQL コミュニティに貢献いただき、ありがとうございます。

そして、いつも MySQL をご利用いただきありがとうございます。

参考資料と公式リソース