a9s Data Service Sunrise/Sunset for Major Versions
Introduction
This document describes the a9s Data Services' release policies, as well as their different release phases.
a9s Data Service Framework Maintenance and Upgrade Policy
Development of new features always takes place against the newest released version of the a9s Data Service Framework (anynines-deployment release). The same applies to bug fixes and patch-level updates to our a9s Data Service automation, vendor software, supporting framework components and runtimes; like Ruby or Java.
In general, critical bug fixes and security-relevant patches are not backported to previous (major) releases of anynines-deployment. Instead, our support team will provide, on-demand, hotfixes that can be applied by the customer on previous major releases of anynines-deployment.
We follow the semantic versioning specification for assigning version numbers to releases, thus upgrading to the latest minor version of that same major version is usually possible without encountering incompatible changes.
For major releases of anynines-deployment, we loosely follow a release-train model with a fixed and reliable schedule. Usually, we release a new major version which includes all the new features, fixes and breaking changes every 4 weeks. The schedule might be extended, thereby delaying the next planned major release delayed, only if anynines deems it necessary. For example, an unexpected delay in the completion of an important or extensive feature like a major Data Service update may cause a delay in the delivery of the next major releases of anynines-deployment.
Normally, minor releases are created infrequently and/or on demand only and generally include patches rather than features. For example, in the event that a highly critical security patch has to be delivered before the due date of the next planned major release, or in case a software regression occurred in the previous release.
Upgrading anynines-deployment is only possible between two consecutive major releases, e.g. from v33.1.0 to v34.0.0, but not from v28.0.0 to v34.0.0. This is due to the fact that upgrades and automated migrations are only tested against the next higher major version. While skipping a major upgrade of anynines-deployment by following the migration instructions of the related release notes is theoretically possible, this is neither recommended nor supported by anynines.
a9s Data Services Release Cycles
In general, anynines aims to support at least two supported (long-term releases) versions of a vendor software (e.g. Redis) within a9s Data Services at the same time. This allows our customers to upgrade existing a9s Data Service instances to a newer and fully supported version of the vendored software before the current version is declared end-of-life (EOL) by their vendors and thus no longer receives bug fixes or security patches.
In consequence, the release cycle and EOL policy of a9s Data Services is mainly determined by the release cycle of the vendor software. Please note that some vendors do not offer LTS versions and some do release new major versions more frequently than others. The following table gives a rough overview on the major releases' schedule of the vendor software used by a9s Data Services:
With respect to those different release frequencies, we do not always support all consecutive major versions provided by the vendor software used by a9s Data Services, e.g. PostgreSQL 13 and 15 but not 14. Thus, we reserve the right to skip certain major versions if this is reasonable and a data migration between the latest two versions supported by our automation framework is possible.
a9s Data Services Maintenance Policy
Each Data Service vendor defines an individual release policy that outlines how they handle new releases, updates, and support for their Data Services. The key points impacting the release policy of the respective a9s Data Service are the release cadence and the maintenance period of the upstream Data Service. Release cadence is the planned frequency at which the vendors release new major versions of their Data Services, maintenance period is the duration during which a particular version of a Data Service receives updates and support from the vendor, including critical security patches and bug fixes.
Thereby, the key factor that influences the release cadence of an a9s Data Service as well as the choice of which particular major version is integrated by anynines, is the maintenance overlap period. This period represents the time frame during which both a new major version and the previous versions of the particular upstream Data Service are actively supported (maintained) by their vendor. Within this overlap period both anynines and its customers have to plan, test, and implement the integration and upgrade to the new Data Service version, before the previous version becomes end-of-life. Accordingly, the maintenance overlap period of an a9s Data Service is the time period between the release of a new major GA version of an a9s Data Service and the upstream EOL date of the latest supported version of that Data Service.
For each a9s Data Service, anynines aims for a maintenance overlap period of at least 6 months, to give customers enough time to upgrade before a Data Service is declared end of life by its vendor. For Data Services with rather long maintenance (overlap) periods of several years such as PostgreSQL or MariaDB LTS, this is no problem. For other Data Services with high release cadence and/or rather short or even no maintenance overlap period at all, like RabbitMQ, anynines cannot guarantee a maintenance overlap period of 6 months.
In such a case the following rule is applied: If an a9s Data Service GA Release Version n is published later than 3 Months before the upstream Data Service Version n-1 becomes end-of-life, the deprecation of the a9s Data Service Version n-1 will not be performed at the same time as the upstream end-of-life date, but at least 3 Months after the release date of a9s Data Service GA Release Version n.
a9s Data Services Life-Cycle Stages
Every a9s Data Service version gets categorized into the following stages:
- Generally Availability (GA)
- Release Candidate (RC)(Non-GA)
- Beta (Non-GA)
- Deprecated
- Unsupported
In terms of life-cycle stages of releases of individual a9s Data Services, we distinguish between a9s Data Service's releases that we consider generally availability (GA) and those that we do not (Non-GA).
A major version of an a9s Data Services goes through the following GA and Non-GA life-cycle stages:
BETA (optional) → RC → GA → DEPRECATED → UNSUPPORTED
General Availability
General Availability (GA) is the release of an a9s Data Service version to the general public. When an a9s Data Service version reaches GA, it becomes officially available in the a9s Data Services Bundle, as opposed to a limited, Non-GA release, used primarily for testing, migration, preparation, and user feedback purposes.
By definition, an a9s Data Service classified as GA can be used in production environments without any restrictions and is fully supported by anynines until it becomes deprecated.
Timeline
Before an a9s Data Service version is called GA, it must have passed through at least one Non-GA release stage. This means that there is a delay of at least one major release cycle of anynines-deployment (4-6 weeks) between the initial release of an a9s Data Service version and the declaration as GA release.
An a9s Data Services' version stays GA as long as the underlying vendor software is supported. Thus, the duration of the GA stage heavily depends on the version and maintenance policies of the vendor.
Non-General Availability
If a particular a9s Data Service version is classified as non-generally available (Non-GA), a further distinction between several Non-GA levels is needed to define the suitability for production purposes and the level of support that is provided by anynines.
Depending on the level of Non-GA, an a9s Data Service version can still be used in production environments, although some restrictions and/or precautions may apply. Therefore, new Beta and RC versions are not included in the a9s Data Services' manifests by default and have to be explicitly enabled by the Platform Operator via separate Ops files. Pleaserefer to the Enable Non-GA Services section of the installation guide for more information.
The different Non-GA levels in the release life-cycle of an individual a9s Data Service and the a9s Data Services Framework as a whole are explained in the following:
Beta
Beta is an optional stage that we mainly reserve for entirely new a9s Data Services or extensive major version updates to give Platform Operators and Application Developers the opportunity to try the a9s Data Service out in a controlled, non-production environment. We encourage our users to provide valuable feedback for further improvements of the service before we officially include them in our a9s Data Services Bundle as GA release.
Software defects ("bugs") reported via our support portal during the Beta stage will be addressed with priority so that they can be resolved before the service enters the RC stage.
An a9s Data Service in Beta stage can be considered a preview of the upcoming service. It is neither guaranteed that it is feature complete nor that seamless updates between minor versions are possible. As long as an a9s Data Service is in Beta stage, breaking changes may be introduced, even between minor versions of a Beta release.
In consequence, a Beta service is not meant to be used in a production environment and not covered by 24/7 support. Any limitation is explicitly documented in the release notes as well as in the end user documentation.
Use Cases
From end user perspective, a Beta version could be used for the following scenarios:
- Let the Platform Operator integrate the Beta version with the current automation in place to ship a9s Data Service versions. This way everything is in place to change to RC or GA stage more quickly.
- Let the a9s Data Service Smoke Tests run in order to check initial compatibility with the platform environment but hide the Beta version from anybody else.
- Let the Application Developers or special user groups test their applications against the upcoming version and the new or changed API to prepare any application-level changes.
- Let the Application Developers or special user groups test the migration of data from previous versions and report any issues back to anynines to let them improve the migration and upgrade procedure.
In case the Beta service is offered to a group of early adopters or testers, it might be appropriate to mark the service explicitly via naming as Beta software or upcoming "preview" in the catalog or marketplace.
Timeline
The duration of the Beta stage depends on several factors and lasts at least one major release cycle of anynines-deployment. If the Beta version is not feature complete or does not yet meet essential Enterprise Readiness Criteria, the Beta stage will usually take more than one major release cycle. After the Beta follows the RC stage.
Release Candidate
Release Candidate (RC) is a mandatory stage that both new a9s Data Services and new major versions of already existing a9s Data Services must go through before they can be called GA. The only difference between RC and GA is that a RC usually hasn't been widely used in production environments yet and might misbehave in some rare edge cases that we cannot detect in our thorough unit and integration tests.
Software defects ("bugs") reported via our support portal during the RC stage will be prioritized so that they can be resolved during the RC stage before it becomes GA.
A RC must meet all Enterprise Readiness Criteria (high availability, encryption, backups, etc.) and must have undergone all the quality assurance and manual and automated testing procedures required to call it GA. For example, it must offer a migration path from the latest generally available a9s Data Service version of the same type. While breaking changes that require a migration/recreation of existing a9s Data Service Instances might happen between Beta and RC releases, they must not happen between RC and GA releases. In consequence, seamless in-place updates from RC to GA instances must be supported.
A RC is production ready and covered by 24/7 support.
Nevertheless, before widely rolling out a RC on the whole platform, we recommend making it available to a small user group only and performing some extensive real-world tests in non-production environments first.
Use Cases
In addition to the use cases of an optional Beta release, a RC could be used for the following scenarios:
- Offer the RC as "preview" version to early adopters that want to use the service before it officially becomes GA
It might be appropriate to mark the service explicitly via naming as Non-GA in the catalog or marketplace.
Timeline
The duration of the RC stage is usually one major release cycle of anynines-deployment. In case software defects are reported during the RC stage, it might be prolonged until those issues have been resolved.
Deprecated
A generally available a9s Data Service version will automatically enter the deprecation phase approximately three major release cycles of anynines-deployment (12-18 weeks) before the underlying vendor software is declared EOL. At this point in time, a newer GA version of the respective a9s Data Service must exist to allow users to migrate their now deprecated instances to a fully supported GA version.
Normally, a deprecated a9s Data Service version can only receive limited support from anynines. It will eventually be removed from the a9s Data Services Bundle and should no longer be used in any environment, whether production or non-production.
During the deprecation phase, the a9s Data Service version will continue to receive critical bug fixes and security patches (if available), but no new features.
For the duration of the deprecation phase, the same level of support as for GA releases will be given by anynines. However, it cannot be guaranteed that bugs or security issues in the vendor software can be fixed after the vendor has discontinued support.
Use Cases
The only valid use case of a deprecated a9s Data Service version is to prepare and perform the migration to the next higher supported GA version. Thus, as soon as an a9s Data Service version enters the deprecation stage, the Platform Operator should disallow the creation of new a9s Data Services instances for it.
Timeline
As a general rule, the deprecation phase starts 3 months (three major release cycles of anynines-deployment) before the EOL date of the vendor software used by the a9s Data Service, with a deprecation announcement. It usually ends 3 months after the EOL, with an unsupport announcement. Thus, owners of deprecated a9s Data Service Instances are granted an additional buffer period of at least 6 months to migrate to a fully supported GA version after the upstream Data Service version has become end-of-life.
In exceptional cases, this period can be extended by anynines. For example, if the delivery of the next GA version is delayed or the migration requires more time, e.g. due to breaking API changes or the necessity to migrate to a different a9s Data Service (e.g. from a9s Elasticsearch to a9s Search). In general an a9s Data Service is not declared deprecated earlier than 3 months after the release of the next upgradeable GA version of that service, so that there is always a time frame of at least 6 months for migrating to the next version before the previous version becomes unsupported.
Unsupported
After the deprecation phase has ended, the creation of new a9s Data Service Instances for this particular version is disabled by default in the a9s Data Services Bundle and the version is no longer supported by anynines. Please refer to the Enable Non-GA Services section of the installation guide for more information.
As the a9s Data Service version is no longer part of the a9s Data Services Bundle and all owners of respective instances should have migrated during the deprecation phase, anynines does not provide regular support for those instances.
Although we won't intentionally break running instances of a no longer supported a9s Data Service versions, it cannot be guaranteed that they still work as expected after an update to an anynines-deployment version which no longer officially supports these versions.
As those versions are no longer considered production ready nor GA, respectively, any kind of extended support is subject to a separate agreement between anynines and the customer.
As soon as an a9s Data Service version enters the unsupported stage, the creation of new instances of this particular version will be disabled by default in anynines-deployment by removing the service offering from the manifest files. Although the Platform Operator still has the option to re-enable the offering, they shouldn’t allow the creation of new instances of this version and should encourage owners of existing instances to migrate before the version is finally removed from the a9s Data Services Bundle.
Use Cases
A migration to a supported version cannot be performed within the regular time frame of the deprecation phase (up to 36 weeks) or within an additional extension period granted by anynines on a voluntary basis. Owners of such instances have to get in contact with anynines sales department to talk about possibilities and conditions for an extended support period or assistance to migrate outdated instances to a supported (GA) a9s Data Service version.
a9s Data Service Release Lifecycle Table
| a9s DS Name | Vendor DS Name | Vendor DS Version | EOL in Vendor | DS State |
|---|---|---|---|---|
| a9s LogMe2 | Fluentd | 1.16.4 | - | 🟩 |
| OpenSearch | 2.16.0 | - | ||
| OpenSearch Dashboards | 2.16.0 | - | ||
| a9s KeyValue 8 | Valkey | 8.0.1 | ? | 🟧 |
| a9s MariaDB 10.6 | MariaDB | 10.6.19 | 2026-06-06 | 🟩 |
| a9s MariaDB 10.11 | MariaDB | 10.11.9 | 2028-02-16 | 🟩 |
| a9s Messaging 3.10 | RabbitMQ | 3.10.25 | 2023-07-31 | 🟥 |
| a9s Messaging 3.12 | RabbitMQ | 3.12.14 | 2024-06-01 | 🟩 |
| a9s Messaging 3.13 | RabbitMQ | 3.13.7 | 2024-10-31 | 🟩 |
| a9s Messaging 4.0 | RabbitMQ | 4.0.2 | ? | 🟧 |
| a9s MongoDB 5.0 | MongoDB | 5.0.28 SSPL[2] | 2024-10-31 | 🟥 |
| a9s MongoDB 7.0 | MongoDB | 7.0.14 SSPL[2] | 2026-08-31 | 🟩 |
| a9s MySQL 10.4 | MariaDB | 10.4.34 | 2024-06-18 | 🟩 |
| a9s PostgreSQL 10 | PostgreSQL | 10.23 | 2020-11-10 | 🟥 |
| a9s PostgreSQL 11 | PostgreSQL | 11.22 | 2023-11-09 | 🟥 |
| a9s PostgreSQL 13 | PostgreSQL | 13.16 | 2025-11-13 | 🟩 |
| a9s PostgreSQL 15 | PostgreSQL | 15.8 | 2027-11-11 | 🟩 |
| a9s Redis 6 [4] | Redis | 6.2.16 | 2023-08-15 | 🟥 |
| a9s Redis 7 [3] | Redis | 7.2.6 | 2025-08-31 | 🟩 |
| a9s Prometheus[5] | Prometheus | 2.53.2 | 2025-07-31 | 🟧 |
| Grafana | 10.3.3 | ? | ||
| Alertmanager | 0.27.0 | ? | ||
| a9s Search 1 | OpenSearch | 1.3.6 | 2023-12-31 | 🟥 |
| a9s Search 2 | OpenSearch | 2.17.1 | ? | 🟩 |
- 🟩: Generally Available (GA)
- 🟨: Release Candidate (non-GA)
- 🟧: Beta (non-GA)
- 🟥: Deprecated
Footnotes
[1]: This cadence does not apply for LTS releases of MariaDB.
[2]: SSPL - Server Side Public License
[3]: a9s Redis 7 is tracking Redis 7.y.z releases.
[4]: a9s Redis 6 is tracking Redis 6.y.z releases.
[5]: a9s Prometheus is still in Beta phase. Please be aware that you might encounter some unexpected issues, as stated
before in the section regarding the Beta phase.