Upgrading Hybrid Manager Innovation Release

Hybrid Manager (HM) offers a dual release strategy: Long-Term Support (LTS) Releases and Innovation Releases (IR). Because these streams follow different versioning logic, the supported paths for moving among them depend on your current version and the target environment.

Release types

Innovation Releases (IR) are delivered monthly. They focus on continuous platform hardening, workflow improvements, stability, reliability, and introduce smaller, iterative new features. They are ideal for customers and teams that want early access to the latest capabilities and want to follow the leading edge of product development.

Long-Term Support (LTS) releases are delivered twice a year. They consolidate the innovations from preceding monthly releases into a stable, well-tested foundation suited to production deployments that require predictability and an extended support window. Each LTS release is supported for 15 months from its release date, with monthly patch releases throughout that period delivering bug fixes and security updates.

IR upgrade paths

You must upgrade month-to-month within the IR stream (for example, 2025.10 → 2025.11). Each IR cycle runs until a consolidation point, where a new LTS version is released. To continue receiving updates after a consolidation point, you must transition to the newly released LTS version (for example, 1.5.0), which then serves as the foundation for the next IR cycle.

LTS upgrade paths

LTS releases follow standard semantic versioning (major.minor.patch, for example, 1.4.x). These versions focus on stability, receiving monthly patch releases with bug and security fixes for their full support lifespan.

Minor and patch version upgrades

To upgrade to the next minor version (for example, 1.3.latest to 1.4.0), you must be on the latest available patch of your current minor version first.

Within the same minor version, patch upgrades are flexible: you may upgrade from any patch to any higher patch (for example, 1.3.1 to 1.3.5) without installing intermediate patches.

Major version upgrades

When a new major version (for example, 2.0) is released, you must be running the latest available minor and patch release of the 1.latest.latest stream to perform the upgrade.

Cross-stream upgrade paths

Moving between LTS and Innovation Releases is possible but has specific constraints.

Innovation Release to LTS

You can move from the final Innovation Release of a cycle to the LTS release that consolidates those features, but not from any other IR in the cycle.

To determine if your current IR supports transitioning to LTS, check the upgrade instructions for that specific version—they indicate whether the transition is supported.

LTS to Innovation Release

You can upgrade an LTS release to its immediate succeeding Innovation Release. You can't jump to an arbitrary or later IR—upgrade to the immediate successor first, then follow the sequential IR upgrade path.

Service availability during upgrades

Some upgrades may trigger an automatic restart of your HM-managed Postgres database clusters. To avoid unexpected interruptions, check the service availability notes in the specific upgrade guide you are following.

Scenario changes on upgrade

Several installation scenarios change across Innovation Releases 2026.8 and 2026.9. Check your HybridControlPlane manifest against the ones that apply to your upgrade path.

The marketplace scenario

marketplace is a separate scenario from core and consists of the kapp package manager and the OSS Library apps it deploys, such as Superset, Airflow, and pgAdmin.

• If your HybridControlPlane spec already includes the ai scenario, marketplace is added automatically during the upgrade. No action is required.
• If your spec lists only core (without ai) and you use the OSS Library/marketplace apps, you must explicitly add marketplace to your spec.scenarios list. Do this before upgrading to Innovation Release 2026.8 or later:

spec:
  scenarios:
    - core
    - marketplace
    - <other_scenarios>

The dbaas scenario

dbaas isn't new, but its contents changed in Innovation Release 2026.8. In 2026.7, upm-api-gucs and pg4k-additional-controllers belonged to core. From 2026.8, they belong to dbaas instead.

A 2026.7 installation that pins spec.scenarios to core is already running both components. After the move, they fall outside every scenario that installation selects, and the upgrade removes them.

• If your spec lists scenarios explicitly, add dbaas before you upgrade:

spec:
  scenarios:
    - core
    - dbaas
    - <other_scenarios>

• If you omit spec.scenarios entirely, the set that applies depends both on your operator version and on what is already stored on the resource. Operator 2.1 fills an empty list with core, dbaas, ai, analytics, migration, and marketplace; operator 2.2 or later fills it with core alone. Rather than reasoning about the default, read the stored list back:

kubectl get hybridcontrolplane <name> -o jsonpath='{.spec.scenarios}'

Add dbaas explicitly if it isn't there.

The pgd scenario

From Innovation Release 2026.9 onwards, pgd — which provisions and manages Distributed High Availability (DHA) clusters — is controlled by its own installation scenario, separated from dbaas.

If you use DHA clusters, you must explicitly add pgd to your spec.scenarios list before upgrading to Innovation Release 2026.9 (even for secondary locations).

Upgrading multi-DC deployments

In a multi-DC deployment, all locations must run the same HM version. The Beacon server on the primary and the Beacon agents on the secondaries must run the same version to communicate reliably and provide full feature functionality.

When upgrading a multi-DC deployment, upgrade the primary location first, then upgrade each data-only secondary location to the same version immediately after. For the full procedure, see Upgrading a multi-DC deployment.