PhoenixAI 26.2 and the new release model
Why this release is numbered 26.2, how often releases arrive from here, and how long each one is supported.
At a glance
- The release after v4.1 is v26.2. Same database kernel. It now has its own version line, separate from open-source StarRocks, and the number changed to reflect that. Nothing else did.
- What used to take three to five months now takes one to two. A capability or a fix you are waiting on arrives in weeks rather than a quarter, and each release carries a fraction of the change, so there is less to validate when it does.
- Speed and stability are separate choices now. Stay on the LTS line and you upgrade at most twice a year, each release supported for 12 months, with a further 6 to complete the move to the next one. Or track the latest and take each capability as it lands. Neither choice costs you the other.
- The LTS line does not restart with the new numbering. v4.0 and v4.1 are LTS releases and stay supported. The next one is v26.3, expected around the end of October.
Why this release is numbered 26.2
Until v4.1, the PhoenixAI database kernel and the open-source StarRocks project shared one set of version numbers. They no longer do. The kernel is developed on its own line, at its own pace, and now carries its own version numbers.
This release is the one that would previously have been numbered v4.2. To keep the change easy to follow, the minor number was kept and only the generation changed: v4.2 became v26.2. From here the kernel counts forward on its own — v26.3, v26.4, and so on.
How versions are numbered
The format is YY.MINOR.PATCH.
| Part | Meaning |
|---|---|
YY | The product generation, matching the year that generation began — 26 for 2026. |
MINOR | Counts minor releases within the generation. A minor release is where new capabilities arrive. |
PATCH | Counts bug-fix releases within a minor release. |
For example, in v26.2.1: generation 26, the second minor release of that generation, first patch.
Versions v4.1 and earlier use the previous MAJOR.MINOR.PATCH scheme. Those versions keep their original numbering for as long as they are supported.
Relationship to open-source StarRocks
Open-source StarRocks continues as an Apache 2.0 project on its own 4.x line and its own release schedule, and PhoenixAI contributes to it.
The two sets of version numbers are independent and cannot be compared. A higher number on one side does not mean newer code on the other, and you cannot infer one version from the other.
Release cadence
Nothing about the kind of release has changed. A minor release is still a minor release; they simply arrive every one to two months, where they previously arrived every three to five.
Two things follow. Capabilities reach you sooner, because finished work is not held back waiting for the next large bundle. And each release carries less change, which makes it faster to validate and safer to adopt — a release that changes ten things is a different proposition from one that changes a hundred.
Releases go out when they are ready rather than to a fixed date. Holidays and the occasional larger release mean the real interval is one to two months rather than exactly thirty days.
| Release type | How often | Supported | For |
|---|---|---|---|
| LTS | A minor release designated for long-term support, about twice a year, around April and October | 12 months, then 6 months to migrate off | Staying put between upgrades |
| Minor release | Every one to two months | While it is one of the three most recent | Getting a capability sooner |
| Patch | As needed | Follows the release line it belongs to | Everyone, on whichever line you run |
LTS is about how long a release is supported, and how often you have to upgrade. An LTS release is supported for 12 months, with 6 months after that to migrate to the next one, and you can move from one LTS straight to the next without going through the releases in between — at most two upgrades a year.
The designation says nothing about maturity. An LTS release goes through the same stages as any other release, and where a particular version stands is published separately, in Release Maturity and Version Status.
How long a version is supported
Minor releases are supported for as long as a version is one of the three most recent. Support is counted in releases, not in months: if a release slips, the window moves with it rather than expiring while you wait for somewhere to go.
The practical rule is: do not fall more than two releases behind the latest.
LTS releases are supported for 12 months. After that there is a further 6 months in which to complete the move to the next LTS. That tail is migration time, not an extension of support: plan the upgrade inside the 12 months rather than into the 6.
Two LTS releases are normally inside the supported window at any time, so there is always a current LTS to move to.
Version numbers here are illustrative. The rule is what matters: three minor releases at a time, sliding forward as we ship, with the long-term releases supported independently on their own 12-month clock, plus 6 months to migrate off.
Which version should you run
There are two ways to stay on a supported version. The difference is not quality — it is how often you upgrade, and how long each version is supported.
| Long-term support releases | Latest minor releases | |
|---|---|---|
| Best for | Fewest upgrades, longest support | Capabilities sooner, shorter support |
| Upgrades per year | At most two | Two to four |
| Supported for | 12 months, then 6 months to migrate | While it is one of the three most recent |
| Next / switching | Next one: v26.3, around the end of October 2026 | Switch to LTS any time; there is always a current one |
Long-term support releases: Settle on an LTS release and stay there. Two arrive each year, and you can move from one LTS directly to the next without passing through the releases in between.
Latest minor releases: Take a minor release when it contains something you need sooner. Stay within two releases of the latest, and settle on the next LTS when it arrives.
The short version: stay on an LTS release if you want to upgrade as little as possible. Take a minor release when you need a capability sooner, and expect to stay reasonably current until the next LTS picks you up.
For how production-ready a particular version is, see Release Maturity and Version Status, which list the current version at each stage.
Upgrading and rolling back
Each release note opens with an Upgrade and compatibility section listing changed defaults, removed options, and anything else that takes effect on upgrade without action on your part. An upgrade plan can be built from the release note itself.
If an upgrade does not go as planned, you can roll back. Each release note names the version it supports rolling back to — for v26.2, the latest v4.1 patch release.
For a production upgrade, contact the PhoenixAI support team or issue a support ticket, and we will walk the compatibility section through with you, agree a validation and rollback plan, and schedule it.
Release notes
Release notes are published with the documentation for your product — PhoenixAI Cloud or PhoenixAI Anywhere — and cover both the database kernel changes in a release and anything specific to that product. A kernel change that has not reached your product does not appear in its release notes.
Going forward, the release note is the complete record of a release:
- Every change that affects behavior is documented, not only the headline features.
- Every entry states its default and the setting that controls it.
- Compatibility comes first, at the top of every release note.
- Features link to their reference documentation.
Questions
Do I have to upgrade every month?
No. If you run an LTS release you upgrade at most twice a year, and you can move from one LTS to the next without stopping at the releases in between.
The faster cadence is an option, not an obligation. It exists so that a capability you need does not have to wait three to five months.
If I take a minor release, am I committed to upgrading regularly?
Yes, but the clock is counted in releases rather than weeks: you can be at most two releases behind the latest. At a one-to-two-month cadence that works out to an upgrade every three to six months.
We would rather say this plainly than have you discover it later. If that cadence does not suit your change-management process, run LTS — that is what it is for, and the current LTS is always available to move to.
What happens if I stay on v4.1?
v4.1 is a long-term support release and stays supported for the rest of its window. A newer version existing is not a reason to move; you move when you are ready to.
Which version you move to is a separate question, and a higher number is not the answer to it. The right target depends on what your cluster runs and what you need from it, so agree it with the support team rather than defaulting to the newest.
Can I roll back if an upgrade goes wrong?
Yes. Each release note names the version it supports rolling back to — for v26.2, the latest v4.1 patch release.
You would lose any capability that exists only in the newer release, which is the trade. If you are planning an upgrade of a production cluster, talk to your account team first and we will agree the rollback plan with you before you start.
Will a minor release change how my queries behave?
Not on its own. Work that could affect how existing queries run — a new optimizer rule, a different execution path, a new reader — ships behind a setting and is left switched off. Upgrading gives you the code; you decide when to turn it on and test it. Work that adds something without touching existing behavior, such as a new function, new syntax or a new data source, simply arrives.
A setting of that kind is switched on by default only once it has been proven across enough workloads. That is a judgement about the capability, not a date, so it does not happen on a fixed release. When it does happen it is recorded as a changed default in the Upgrade and compatibility section at the top of that release note, together with the setting that turns it back off.
This is why the Upgrade and compatibility section comes first in every release note: it is the short list of what changes without you asking, and it is what an upgrade plan is built from.
What does LTS mean, and how is it different from any other release?
LTS stands for long-term support. Two things follow from the designation.
It is supported for longer. 12 months of support, then 6 months in which to complete the move to the next LTS. A minor release that is not designated LTS is supported while it is one of the three most recent, which at this cadence is three to six months.
You can stay on the LTS line. Each LTS release upgrades directly to the next, so you skip the releases in between and upgrade at most twice a year instead of every one to two months.
What LTS does not mean is a maturity grade. An LTS release goes through the same stages as any other, so it is not automatically the more mature choice on the day it ships. Where a specific version stands is published in Release Maturity and Version Status.
Why did the number jump from 4.1 to 26.2?
Because the database kernel now has its own version line, separate from open-source StarRocks. 26 is the product generation. This release is the one that would have been v4.2, so the minor number was kept and only the generation changed.
Is v26.2 a bigger or smaller release than v4.1?
Bigger. It carries everything that accumulated after v4.1 was branched. The 2 counts minor releases within the 2026 generation; it says nothing about size.
v26.2 is the last release of this size. From v26.3 onward each release carries one to two months of work rather than five.
Where do I find release notes?
With the documentation for your product. PhoenixAI Cloud and PhoenixAI Anywhere each have their own release notes, covering the database kernel changes in a release together with anything specific to that product.
Is anything different between PhoenixAI Cloud and PhoenixAI Anywhere?
The database kernel is the same. What differs is how a capability is exposed and when it reaches you. A release goes to PhoenixAI Cloud first and to PhoenixAI Anywhere afterwards, once it has settled — self-managed clusters are deliberately kept on a more conservative version. Some capabilities also exist only in one of the two.
The release notes for your deployment cover both: the kernel changes in the release, and the changes specific to that product. A kernel change that has not reached your deployment does not appear in its release notes.
How do I plan an upgrade?
Talk to your account team. For a production upgrade we will walk the compatibility section through with you, agree a validation and rollback plan, and schedule it.