OpenStack conversations often oscillate between two extremes: either “it’s legacy” or “it’s the backbone of sovereign cloud.” The reality is that OpenStack is still very alive — but it’s run by teams who care deeply about release planning, not hype. If you operate OpenStack, the release calendar is one of your best operational tools.
The official OpenStack Releases site lays out the current series, their phases, and key dates. This week is a good time to look at it because the next cycle, 2026.1 (Gazpacho), is on the horizon with an estimated initial release date of 2026-04-01.
OpenStack’s cadence in one sentence
OpenStack releases on roughly a 6‑month schedule, and after the initial release the ecosystem continues with stable point releases and maintenance phases. That’s normal for infrastructure — but it means your upgrade planning needs to think in terms of phases, not just “versions.”
Maintenance phases matter more than version numbers
When the releases site shows a series as “Development,” “Maintained,” “Unmaintained,” or “End Of Life,” it’s telling you what kind of upstream support posture you can expect. In practical terms:
- Maintained: stable branches get fixes and point releases; you can justify staying on the branch while planning your next step.
- Unmaintained: you’re increasingly on your own; security and bug fix velocity drops.
- EOL: you should have already moved; risk accumulates quickly.
For large private clouds, the cost of upgrading is real — but so is the cost of lingering past the point where you get meaningful upstream fixes.
SLURP: why some releases are special for upgrades
The releases site also flags which releases use the “Skip Level Upgrade Release Process” (SLURP). SLURP releases matter because they define officially supported upgrade paths that can skip a release. This is a pragmatic recognition that not every operator upgrades every six months.
If you’re planning upgrades for 2026, you should explicitly map your current series to your target series and determine whether the path is adjacent-only or SLURP-enabled. Your vendor’s distribution and your deployment tooling (Kolla, OpenStack-Ansible, Juju, etc.) will also influence how smooth that path is.
How to use the release calendar as an operator
Operators should treat the OpenStack release calendar like a product roadmap with operational constraints. A simple process looks like this:
- Pick your target series (for many teams, Gazpacho is the next major waypoint).
- Identify your current support posture: are you on a maintained or unmaintained branch?
- Align with your vendor: distribution packaging lag is real; upstream dates aren’t always your installable dates.
- Schedule upgrades around business windows: treat control plane upgrades like major platform events.
- Plan for iterative validation: upgrade one cell/region first when possible.
Why this connects to “sovereign cloud” conversations
OpenInfra messaging increasingly centers on sovereignty, locality, and avoiding lock-in — especially as geopolitical and data residency pressures increase. But sovereignty isn’t just a procurement decision. It’s an operational posture: you need a predictable upgrade path, a supportable security story, and a clear lifecycle plan for your core cloud control plane.
That’s why the boring stuff (calendars, phases, release processes) is actually the most important part of the OpenStack story in 2026.
What to do next if you’re targeting Gazpacho
- Subscribe to the combined release calendar so changes aren’t surprises.
- Review your current series and confirm whether it’s maintained.
- Start a lab upgrade rehearsal now; don’t wait for the initial release date.
- Inventory integrations: external auth, storage backends, SDN, and any custom automation.