Versioning

XTrinode uses semantic versioning for the public control-plane release line. The Helm chart versions, umbrella chart dependency versions, control-plane component image tags, and documentation should move together for a given release.

The managed Trino runtime image is pinned separately because Trino compatibility is a runtime decision, not a control-plane release decision.

Current Release

Item	Version
XTrinode release line	0.1.0
XTrinode Helm chart version	0.1.0
XTrinode component image version	0.1.0
Public release image architecture	linux/amd64
Default Trino runtime image tag	480
Upstream Trino chart compatibility target	trino-1.42.2

For the wider toolchain and dependency matrix, see Compatibility.

Component Images

The current public control-plane images are published through GitHub Container Registry:

ghcr.io/xtrinode/xtrinode-operator:0.1.0
ghcr.io/xtrinode/xtrinode-api-server:0.1.0
ghcr.io/xtrinode/xtrinode-gateway:0.1.0

Use exact image tags for reproducible deployments.

Release image publishing currently builds linux/amd64 images only. If you run arm64 nodes, build and publish your own arm64 images or constrain the control-plane pods to amd64 nodes.

Release pushes create these image tags from the component image version:

Tag	Meaning
0.1.0	Exact release image version
0.1	Latest patch for the minor release line
0	Latest minor release for the major line
latest	Latest stable release; prereleases do not receive this tag

Included Features

The current release includes:

• Kubernetes-native XTrinode runtime resources;
• XTrinodeCatalog resources for reusable catalog declarations;
• operator reconciliation for coordinators, workers, services, catalogs, KEDA objects, and gateway route state;
• API server lifecycle coordination for resume and suspend flows;
• gateway routing by hostname, X-Trino-XTrinode header, default route, or shared routing group;
• fixed worker counts and optional KEDA-managed worker scaling;
• auto-resume and auto-suspend lifecycle behavior;
• status conditions, Kubernetes events, gateway metrics, and operational logs;
• Helm packaging for the umbrella chart and component charts;
• GCP/GKE/CAPG integration path with Terraform, GKE, Artifact Registry mirroring, optional per-runtime managed node pools, and KEDA/resume smoke coverage;
• AWS/EKS/CAPA and Azure/AKS/CAPZ Terraform, registry/deploy material, API server auth wiring, and tested node-pool resource generation.

GCP/GKE/CAPG is the fully exercised checked-in live cloud path. Live CAPA/CAPZ parity for AWS and Azure is tracked separately.

Release Tagging

Release tags are created by the main repository release workflow after a CODEOWNER-owned release PR is merged to main. Manual release tag pushes should be blocked by repository rules.

Git tags use a v prefix:

v<major>.<minor>.<patch>

Docker image tags and Helm chart versions use the plain semantic version:

<major>.<minor>.<patch>

For release work, update the chart versions, chart appVersion fields, umbrella dependency versions, the umbrella Chart.lock, Compatibility, and this page together. The release workflow creates the v<major>.<minor>.<patch> tag after CI passes.