Lifecycle policies

This page details lifecycle policies for the Stackable Data Platform (SDP).

Multiple lifecycle policies are defined for different parts of our platform, but all policies follow some common goals:

  • It should always be possible to upgrade to a new version of SDP without also changing any of the Stackable Custom Resources as long as you are not currently using anything that has already been marked as deprecated

    • This means you can upgrade the control plane independently of the user-facing products

  • All deprecations follow a predictable lifecycle that allows planning of upgrades ahead of time

The guarantees we give are on multiple levels as detailed below:

  • The SDP itself

  • CustomResourceDefinition (CRD) versions

  • Supported product versions

  • Supported OpenShift & Kubernetes versions

These policies may evolve based on customer feedback and operational experience.

These policies were last updated in September 2025.

Stackable Data Platform lifecycle policy

We do releases of our Stackable Data Platform. These releases get a name based on the year and month they have been released in (e.g. 25.3, 25.7, also called CalVer). This name does not follow Semantic Versioning (SemVer). We may release patches for a release, which then follow the PATCH naming semantics of SemVer (e.g. 24.7.1) or the Micro name from CalVer. See below for our policy on patches for the SDP.

We support an SDP release for a specific amount of time after its initial release.

An SDP release contains our operators, other components developed at Stackable, and the operator-managed product container images.

Our policy is inspired by the Kubernetes and the OpenShift policies.

Full support phase

This phase begins once a new non-patch SDP version is released and ends after a 6-month period OR 3 months after the general availability of the superseding non-patch release, whichever is later.

The following pictures show both scenarios:

Full Support Scenario 1

Full Support Scenario 2

We will release new patch releases of a SDP release (e.g. 24.11.1) for any issues we deem Critical or High (see definition below) once fixes become available. We may release new patch releases for other reasons.

Maintenance phase

This phase commences after the Full Support phase for the respective SDP version and ends 12 months after general availability of the SDP release.

We may release new patch releases of a SDP release (e.g. 24.11.1) for any issues we deem Critical or High (see definition below) once fixes become available. We may release patches for other reasons.

Maintenance Phase

Upgrade policy

Skipping SDP releases while upgrading is currently not supported. The only upgrade path we test and support is from one SDP version to the next (e.g., 24.11 → 25.3 → 25.7).

Customers are expected to upgrade their SDP environment to the most current supported patch/micro (25.7.z) version.

We test and support upgrades for both our Kubernetes operators and data products. There can be exceptions from this policy for specific data product upgrade paths. These are documented in our release notes.

Downgrades and rollbacks are not supported or tested. While they may work in some cases, customers who downgrade do so at their own risk and without our support.

CRD Versioning lifecycle policy

As of release 25.7 all our CRDs are versioned as v1alpha1. Starting with release 25.11 we will introduce versioned CRDs for some products.

CustomResourceDefinitions at Stackable are versioned.

Our policies around CRD versioning are inspired by the Kubernetes Deprecation Policy.

Specifically we try to follow these rules:

  • API elements may only be removed by incrementing the version of the API group.

  • API objects must be able to round-trip between API versions in a given release without information loss, except for whole REST resources that do not exist in some versions.

  • An API version in a given track may not be deprecated in favor of a less stable API version.

  • API lifetime is determined by the API stability level

    • Alpha API versions may be removed in any release without prior deprecation notice.

    • Beta API versions are deprecated at a minimum of 1 platform releases after introduction and removed at a minimum of 1 platform releases after deprecation.

    • GA (stable) API versions are deprecated at a minimum of 2 platform releases after introduction and removed at a minimum of 1 platform releases after deprecation.

Similar to the Exception noted by the Kubernetes project itself, we will also evolve these policies as we go along and find that one of the rules doesn’t fit a situation.

According to these rules it is legal to add fields to a CRD without increasing the version as long as there is a default for this field.

Operator implementation details

Resources created and managed by Stackable operators (such as Pods, Services, ConfigMaps, StatefulSets, etc.) are considered implementation details of the operators. The structure, naming, labels, and configuration of these resources may change between releases without prior notice. Users should not directly depend on or modify these operator-managed resources.

Product lifecycle policy

SDP ships with a lot of different data products (e.g. Apache HBase, Apache Superset).

All of these products follow their own version semantics and release cadences and lifecycles, which is why we do not define a product lifecycle policy based on version numbers alone.

For every one of the products we ship we always support one LTS (Long Term Support) release line, which we generally recommend to use. A release line usually means that we are going to keep a major.minor release stable but will include newer patch versions in later SDP releases.

Some products (e.g. Trino) don’t follow Semver rules, for those we will follow separate rules and clearly document what version is considered LTS.

Every LTS release line is supported for a minimum of 12 months from the SDP release in which it was introduced. When introducing a new LTS release line, the previous LTS line must remain available (marked as deprecated) for at least one additional SDP release to allow migration time.

For example: If an LTS version is introduced in release 24.3 (March 2024), it must be available as the recommended LTS through at least the March 2025 release (25.3). If a new LTS is introduced in 25.3, the old LTS from 24.3 must remain available but deprecated in 25.3, and can be removed in the following release (25.7).

The line designated as our LTS release is chosen at our own discretion and is based on popularity, upstream lifecycle policies, stability, our own experience and other factors.

In addition to the LTS line we may also ship other versions, e.g. the latest upstream version.

We do honor the same deprecation policy for non-LTS products as for LTS products, but we do not guarantee a long term support for these versions. They may be deprecated faster.

Product Lifecycle Policy

Deprecation

Every product version that gets removed will be deprecated for at least 1 SDP release before removal. This guarantees that users can update the operators (e.g. from 25.3 to 25.7) without the need to simultaneously update the product version as well. The flow is to first update the control plane (the operators) and afterward the product versions if desired (e.g. when the currently used version is now deprecated).

Definition of support

We will ship new versions of the LTS release line in our currently supported SDP releases (see above) for any issues we deem Critical or High in severity when they become available.

We will also engage with the upstream projects to try and solve issues.

It is our explicit goal to limit the amount of times we have to ship a version of the products that deviates from the original upstream source.

We may ship new versions for existing SDP releases for other issues as well.

OpenShift & Kubernetes support policy

For every SDP release we will publish a list of supported Kubernetes versions.

We are aiming to support the last three Kubernetes versions but will make case-by-case decisions by taking into account the currently supported Kubernetes versions. We will also take into account currently supported OpenShift versions as published by RedHat. It is our goal to support all versions that are in Full or Maintenance support. As the releases may be overlapping we might not always support the latest Kubernetes or OpenShift versions when we release a SDP version.

When a Kubernetes or OpenShift version is no longer listed as supported for an SDP release, this means we no longer test the SDP release against that version. The platform may continue to work on unsupported versions, but we make no guarantees. We will not investigate or fix issues that only occur on unsupported Kubernetes/OpenShift versions.

Support policy (security & bugs)

Stackable will analyze published security vulnerabilities (e.g. CVEs but other sources may apply as well) for all the products we support as well components developed by us and their dependencies. We take various sources into account when assigning a criticality. Among those sources is the NVD database, but we place higher value on the self-assessments by the projects themselves, and we will additionally evaluate vulnerabilities in the context of how they are used in the Stackable Data Platform.

We will then assign a criticality to each vulnerability according to similar rating categories that RedHat has established:

Critical

This rating is given to flaws that could be easily exploited by a remote unauthenticated attacker and lead to system compromise (arbitrary code execution) without requiring user interaction. Flaws that require authentication, local or physical access to a system, or an unlikely configuration are not classified as Critical impact. These are the types of vulnerabilities that can be exploited by worms.

High

This rating is given to flaws that can easily compromise the confidentiality, integrity or availability of resources. These are the types of vulnerabilities that allow local or authenticated users to gain additional privileges, allow unauthenticated remote users to view resources that should otherwise be protected by authentication or other controls, allow authenticated remote users to execute arbitrary code, or allow remote users to cause a denial of service.

Medium

This rating is given to flaws that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity or availability of resources under certain circumstances. These are the types of vulnerabilities that could have had a Critical or Important impact but are less easily exploited based on a technical evaluation of the flaw, and/or affect unlikely configurations.

Low

This rating is given to all other issues that may have a security impact. These are the types of vulnerabilities that are believed to require unlikely circumstances to be able to be exploited, or where a successful exploit would give minimal consequences. This includes flaws that are present in a program’s source code but to which no current or theoretically possible, but unproven, exploitation vectors exist or were found during the technical analysis of the flaw.