PhoenixAI 26.2 と新しいリリースモデル
このリリースが 26.2 という番号である理由、今後のリリースの頻度、および各リリースのサポート期間について説明します。
概要
- v4.1 の次のリリースは v26.2 です。 データベースカーネルは同じです。オープンソースの StarRocks とは別に独自のバージョン系統を持つようになり、それを反映して番号が変わりました。変わったのはそれだけです。
- これまで 3～5 か月かかっていたものが、1～2 か月で届くようになります。 お待ちの機能や修正は、四半期単位ではなく数週間単位で届きます。また、各リリースに含まれる変更はごく一部になるため、届いた際に検証すべき内容も少なくなります。
- スピードと安定性を別々に選べるようになりました。 LTS 系統にとどまれば、アップグレードは年に最大 2 回で済みます。各リリースは 12 か月間サポートされ、さらに次のリリースへの移行を完了するための 6 か月間が設けられます。あるいは、最新リリースに追随して、各機能を提供され次第取り入れることもできます。どちらを選んでも、もう一方を犠牲にすることはありません。
- LTS 系統は、新しい番号体系になってもリセットされません。 v4.0 と v4.1 は LTS リリースであり、引き続きサポートされます。次の LTS は v26.3 で、10 月末頃の予定です。
このリリースが 26.2 という番号である理由
v4.1 までは、PhoenixAI データベースカーネルとオープンソースの StarRocks プロジェクトは 1 つのバージョン番号体系を共有していました。現在はそうではありません。カーネルは独自の系統で、独自のペースで開発されるようになり、独自のバージョン番号を持つようになりました。
このリリースは、従来であれば v4.2 という番号になっていたものです。変更をわかりやすくするために、マイナー番号はそのまま残し、世代だけを変更しました。つまり、v4.2 が v26.2 になりました。今後、カーネルは独自に番号を進めていきます — v26.3、v26.4 のように続きます。
バージョン番号の付け方
形式は YY.MINOR.PATCH です。
| 部分 | 意味 |
|---|---|
YY | 製品の世代。その世代が始まった年に対応します — 2026 年なら 26 です。 |
MINOR | 世代内のマイナーリリースを数えます。新しい機能はマイナーリリースで提供されます。 |
PATCH | マイナーリリース内のバグ修正リリースを数えます。 |
たとえば v26.2.1 は、世代 26、その世代の 2 番目のマイナーリリース、最初のパッチを表します。
v4.1 以前のバージョンは、従来の MAJOR.MINOR.PATCH 形式を使用します。これらのバージョンは、サポートされている間は元の番号を維持します。
オープンソースの StarRocks との関係
オープンソースの StarRocks は、独自の 4.x 系統と独自のリリーススケジュールで Apache 2.0 プロジェクトとして継続しており、PhoenixAI もこれに貢献しています。
2 つのバージョン番号体系は互いに独立しており、比較することはできません。 一方の番号が大きくても、もう一方より新しいコードであることを意味するわけではなく、一方のバージョンからもう一方のバージョンを推測することもできません。
リリースの頻度
リリースの種類そのものは何も変わっていません。マイナーリリースは引き続きマイナーリリースです。以前は 3～5 か月ごとだったものが、1～2 か月ごとに届くようになっただけです。
これにより 2 つのことが生じます。完成した成果が次の大規模なまとめを待って保留されることがなくなるため、機能がより早く届きます。そして、各リリースに含まれる変更が少なくなるため、検証がより速く、導入がより安全になります — 10 の変更を含むリリースと 100 の変更を含むリリースとでは、まったく性質が異なります。
リリースは決まった日付ではなく、準備が整った時点で公開されます。休暇期間や、ときおり発生する大規模なリリースのため、実際の間隔はきっかり 30 日ではなく、1～2 か月となります。
| リリースの種類 | 頻度 | サポート | 用途 |
|---|---|---|---|
| LTS | 長期サポートに指定されたマイナーリリース。年に約 2 回、4 月頃と 10 月頃 | 12 か月間、その後移行のための 6 か月間 | アップグレードの間隔をあけて同じバージョンにとどまる |
| マイナーリリース | 1～2 か月ごと | 最新の 3 リリースのいずれかである間 | 機能をより早く入手する |
| パッチ | 必要に応じて | 所属するリリース系統に従う | どの系統を利用している場合でも、すべてのお客様 |
LTS は、リリースがサポートされる期間と、アップグレードが必要な頻度に関するものです。 LTS リリースは 12 か月間サポートされ、その後、次の LTS へ移行するための 6 か月間が設けられます。また、間にあるリリースを経由せずに、ある LTS から次の LTS へ直接移行できます — アップグレードは年に最大 2 回です。
この指定は成熟度については何も示していません。LTS リリースも他のリリースと同じステージを経ます。特定のバージョンがどのステージにあるかは、リリースの成熟度とバージョンステータスで別途公開しています。
バージョンのサポート期間
マイナーリリースは、そのバージョンが最新の 3 リリースのいずれかである間サポートされます。サポートは月数ではなくリリース数で数えます。リリースが遅れた場合、移行先を待っている間にサポートが切れるのではなく、サポート期間もそれに合わせて後ろにずれます。
実践的なルールは、最新リリースから 2 つを超えて遅れないことです。
LTS リリースは 12 か月間サポートされます。その後、次の LTS への移行を完了するための 6 か月間がさらに設けられます。この期間は移行のための時間であり、サポートの延長ではありません。アップグレードは 6 か月間にずれ込ませず、12 か月以内に計画してください。
通常、常に 2 つの LTS リリースがサポート期間内にあるため、移行先となる現行の LTS が必ず存在します。
図中のバージョン番号は説明のためのものです。重要なのはルールです。一度にサポートされるマイナーリリースは 3 つで、新しいリリースが出るたびに前に進みます。一方、長期サポートリリースはそれとは独立して、独自の 12 か月間のサポートと、移行のための 6 か月間を持ちます。
どのバージョンを使用すべきか
サポート対象のバージョンにとどまるには 2 つの方法があります。違いは品質ではなく、アップグレードの頻度と、各バージョンがサポートされる期間です。
| 長期サポートリリース | 最新のマイナーリリース | |
|---|---|---|
| 適している用途 | アップグレード回数が最少、サポートが最長 | 機能をより早く入手、サポートは短め |
| 年間のアップグレード回数 | 最大 2 回 | 2～4 回 |
| サポート期間 | 12 か月間、その後移行のための 6 か月間 | 最新の 3 リリースのいずれかである間 |
| 次のリリース / 切り替え | 次は v26.3、2026 年 10 月末頃 | いつでも LTS に切り替え可能。現行の LTS が常に存在します |
長期サポートリリース: LTS リリースを選んで、そこにとどまります。LTS は毎年 2 つリリースされ、間にあるリリースを経由せずに、ある LTS から次の LTS へ直接移行できます。
最新のマイナーリリース: より早く必要な機能が含まれている場合に、マイナーリリースを採用します。最新リリースから 2 つ以内の遅れにとどめ、次の LTS がリリースされたらそちらに落ち着きます。
要約: アップグレードを最小限にしたい場合は、LTS リリースにとどまってください。機能をより早く必要とする場合はマイナーリリースを採用し、次の LTS に移行するまでは、ある程度最新の状態を保つことを想定してください。
特定のバージョンが本番環境にどの程度対応しているかについては、各ステージの現在のバージョンを一覧にしたリリースの成熟度とバージョンステータスを参照してください。
アップグレードとロールバック
各リリースノートの冒頭には「Upgrade and compatibility」セクションがあり、変更されたデフォルト値、削除されたオプション、その他お客様が何も操作しなくてもアップグレード時に有効になる内容が記載されています。アップグレード計画はリリースノートそのものから作成できます。
アップグレードが計画どおりに進まなかった場合は、ロールバックできます。各リリースノートには、ロールバック先としてサポートされるバージョンが記載されています — v26.2 の場合は、v4.1 の最新パッチリリースです。
本番環境のアップグレードについては、PhoenixAI サポートチームにお問い合わせいただくか、サポートチケットを発行してください。互換性セクションを一緒に確認し、検証とロールバックの計画を合意したうえで、スケジュールを決定します。
リリースノート
リリースノートは、ご利用の製品 — PhoenixAI Cloud または PhoenixAI Anywhere — のドキュメントとともに公開され、リリースにおけるデータベースカーネルの変更と、その製品固有の変更の両方を扱います。ご利用の製品にまだ反映されていないカーネルの変更は、その製品のリリースノートには記載されません。
今後、リリースノートはリリースの完全な記録となります。
- 動作に影響するすべての変更を記載します。主要な機能だけではありません。
- 各項目には、デフォルト値とそれを制御する設定を記載します。
- 互換性を最初に記載します。すべてのリリースノートの冒頭に置きます。
- 機能からはリファレンスドキュメントにリンクします。
よくある質問
毎月アップグレードする必要がありますか？
いいえ。LTS リリースを使用している場合、アップグレードは年に最大 2 回で、間にあるリリースを経由せずに、ある LTS から次の LTS へ移行できます。
より速いリリース頻度は選択肢であり、義務ではありません。必要な機能が 3～5 か月待たされることがないようにするためのものです。
マイナーリリースを採用した場合、定期的なアップグレードが必要になりますか？
はい。ただし、期限は週数ではなくリリース数で数えます。最新リリースからの遅れは最大 2 リリースまでです。1～2 か月のリリース頻度では、3～6 か月ごとに 1 回のアップグレードとなります。
後から気づかれるよりも、はっきりとお伝えしておきたいと考えています。このリリース頻度がお客様の変更管理プロセスに合わない場合は、LTS をご利用ください — LTS はそのためにあり、移行先となる現行の LTS は常に存在します。
v4.1 にとどまった場合はどうなりますか？
v4.1 は長期サポートリリースであり、そのサポート期間が終わるまで引き続きサポートされます。新しいバージョンが存在することは、移行する理由にはなりません。準備ができたときに移行してください。
どのバージョンに移行するかは別の問題であり、番号が大きいことがその答えになるわけではありません。適切な移行先は、クラスターで実行しているワークロードと必要な機能によって決まります。最新バージョンを既定の選択とするのではなく、サポートチームと相談して決定してください。
アップグレードが失敗した場合、ロールバックできますか？
はい。各リリースノートには、ロールバック先としてサポートされるバージョンが記載されています — v26.2 の場合は、v4.1 の最新パッチリリースです。
新しいリリースにのみ存在する機能は失われますが、それがトレードオフです。本番クラスターのアップグレードを計画している場合は、まずアカウントチームにご相談ください。開始前に、ロールバック計画をお客様と合意します。
マイナーリリースによって、クエリの動作は変わりますか？
それだけで変わることはありません。既存のクエリの実行方法に影響を与える可能性のある変更 — 新しいオプティマイザールール、異なる実行パス、新しいリーダーなど — は、設定によって制御され、無効の状態で提供されます。アップグレードによってコードは手に入りますが、それを有効にしてテストするタイミングはお客様が決めます。新しい関数、新しい構文、新しいデータソースなど、既存の動作に影響を与えずに何かを追加する変更は、そのまま提供されます。
このような設定がデフォルトで有効になるのは、十分な数のワークロードで実証された後に限られます。これは日付ではなく機能そのものに関する判断であるため、決まったリリースで行われるわけではありません。有効になった場合は、そのリリースノートの冒頭にある「Upgrade and compatibility」セクションに、デフォルト値の変更として、それを無効に戻す設定とともに記載されます。
すべてのリリースノートで「Upgrade and compatibility」セクションが最初にあるのはこのためです。このセクションは、お客様が何もしなくても変わる内容の短い一覧であり、アップグレード計画の基になるものです。
LTS とは何ですか？他のリリースとはどう違いますか？
LTS は長期サポート（Long-Term Support）の略です。この指定から 2 つのことが生じます。
サポート期間が長くなります。 12 か月間のサポートに加え、次の LTS への移行を完了するための 6 か月間が設けられます。LTS に指定されていないマイナーリリースは、最新の 3 リリースのいずれかである間サポートされ、このリリース頻度では 3～6 か月間となります。
LTS 系統にとどまることができます。 各 LTS リリースは次の LTS へ直接アップグレードできるため、間にあるリリースを飛ばして、1～2 か月ごとではなく年に最大 2 回のアップグレードで済みます。
LTS は成熟度の等級を意味するものではありません。LTS リリースも他のリリースと同じステージを経るため、リリース当日の時点で自動的により成熟した選択肢になるわけではありません。特定のバージョンがどのステージにあるかは、リリースの成熟度とバージョンステータスで公開しています。
なぜ番号が 4.1 から 26.2 に飛んだのですか？
データベースカーネルが、オープンソースの StarRocks とは別に独自のバージョン系統を持つようになったためです。26 は製品の世代です。このリリースは本来 v4.2 になるはずだったものなので、マイナー番号はそのまま残し、世代だけを変更しました。
v26.2 は v4.1 より大きなリリースですか、小さなリリースですか？
大きなリリースです。v4.1 のブランチ作成以降に蓄積されたすべての変更が含まれています。2 は 2026 年世代内のマイナーリリースを数えたもので、規模については何も示していません。
この規模のリリースは v26.2 が最後です。v26.3 以降、各リリースには 5 か月分ではなく 1～2 か月分の成果が含まれます。
リリースノートはどこで確認できますか？
ご利用の製品のドキュメントで確認できます。PhoenixAI Cloud と PhoenixAI Anywhere にはそれぞれ独自のリリースノートがあり、リリースにおけるデータベースカーネルの変更と、その製品固有の変更をあわせて扱っています。
PhoenixAI Cloud と PhoenixAI Anywhere で何か違いはありますか？
データベースカーネルは同じです。異なるのは、機能の提供方法と、お客様に届く時期です。リリースはまず PhoenixAI Cloud に提供され、安定した後に PhoenixAI Anywhere に提供されます — セルフマネージドのクラスターは、意図的により保守的なバージョンに保たれています。また、一方にのみ存在する機能もあります。
ご利用のデプロイメントのリリースノートには、リリースにおけるカーネルの変更と、その製品固有の変更の両方が記載されます。ご利用のデプロイメントにまだ反映されていないカーネルの変更は、そのリリースノートには記載されません。
アップグレードはどのように計画すればよいですか？
アカウントチームにご相談ください。本番環境のアップグレードについては、互換性セクションを一緒に確認し、検証とロールバックの計画を合意したうえで、スケジュールを決定します。