Release channel and version reference

Use this reference to compare release channels, understand the version format, and verify platform compatibility for automation orchestrator.

Channel comparison

Table 1. Release channel comparison
Attribute early-access stable
Intended use Development, feature evaluation Pre-production and production
Support coverage Not supported by Red Hat Full Red Hat support
Update frequency Receives experimental and in-development features Receives releases that pass quality gates
In-place upgrades No Yes

Version format

Automation orchestrator version numbers use the format YYYY.M.TIMESTAMP.

Table 2. Version format segments
Segment Description Example
YYYY Four-digit year 2026
M Month without a leading zero 8
TIMESTAMP UNIX build timestamp 1785678543

Full example: 2026.8.1785678543

The YYYY.M prefix identifies the version series. The initial general availability (GA) release targets the 2026.8 series.

Version series and breaking changes

Red Hat does not introduce breaking changes within a version series. Breaking changes are only allowed when a new version series begins with a new YYYY.M value. A new version series does not always contain breaking changes, because Red Hat also uses version series boundaries for business milestones. When a new series does include breaking changes, the new YYYY.M value gives you advance notice that the upgrade might require changes to your integrations or configurations.

API versioning

Automation orchestrator versions each interface independently of the product version:

Table 3. API versioning by interface
Interface How versions are tracked
REST API URL path versioning (/v1/,/v2/). Red Hat introduces a new path version before any breaking change.
Operator custom resource Kubernetes API versioning (v1alpha1,v1beta1,v1).
Workflow import and export format An explicitversion field in the exported file.

Within a version series, Red Hat does not introduce breaking changes to these interfaces. You can upgrade within a series without modifying your API integrations, custom resource definitions (CRDs), or exported workflow files.

Platform compatibility

The GA release supports the following platform versions:

Table 4. Supported platform versions
Component Supported version
Ansible Automation Platform 2.7 or later
OpenShift Container Platform 4.14 or later
PostgreSQL 15

For the support matrix, see the Ansible Automation Platform lifecycle.

Upgrade constraints

The following constraints apply to in-place upgrades on the stable channel. The early-access channel does not support in-place upgrades.

  • You can skip intermediate versions when upgrading, for example from 2026.8 to 2026.11. The operator runs all intermediate database migrations in sequence. Upgrades that span many versions might take longer. For details, see Understand automation orchestrator upgrades.
  • The operator rejects downgrades because each migration transforms the database schema irreversibly. To roll back to a previous version, restore from a database backup.
  • Automation orchestrator does not support in-place rollback of operator upgrades.