a9s Data Service Sunrise/Sunset for Major Versions

Introdcution

This document describes how and when new major versions are released in the a9s Data Services.

Upstream Release Cycle

The following table gives makes a rough statement how often major releases of an upstream data service per year advertised.

Service~ Major Releases per yearLink
PostgreSQL1https://www.postgresql.org/support/versioning/
MongoDB1-2https://www.mongodb.com/support-policy
Redis2https://redis.io/topics/releases https://redislabs.com/redis-enterprise-documentation/administering/product-lifecycle
RabbitMQ1https://www.rabbitmq.com/changelog.html
Elasticsearch1https://www.elastic.co/support/eol
MySQL0.5https://en.wikipedia.org/wiki/MySQL#Release_history

a9s Data Services Release Cycles

In general a9s aims to support the two latest major versions of a data service. anynines also aims to provide betas for major versions if available by the upstream.

Given the table from section Upstream Release Cycle a major version of an upstream service will be provided in the anynines catalog for ~2 years.

a9s Data Service Stages

Every a9s Data Service version gets categorized into three stages:

  • Beta
  • Release Candidate
  • Stable

Under normal circumstances a new a9s Data Service version will go through all three stages in the order Beta, Release Candidate and Stable.

For certain distribution channels, for example PCF, the customer might see fewer stages, for example Stable only.

Beta

The stage beta for an a9s Data Service version means An upgrade path from Beta to Release Candidate is not supported.

This version could be used for the following scenarios:

  • Let the application developers or special user groups test against the upcoming version.
  • 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 Release Candidate or Stable stage more quickly.
  • Let the a9s Data Service Smoke Tests run in order to check initial compatibility but hide it from anybody else.

It might be appropriate to mark the service explicitly via naming as beta software in the catalog or marketplace.

Release Candidate

The stage Release Candidate for an a9s Data Service version means it’s a beta version with potential to be a final product which is ready to release unless significant bugs emerge. Normally, all product features have been designed and tested. In most cases an upgrade to the stage Stable is supported.

This version could be used for the following scenarios:

  • Let the application developers or special user groups test against the forthcoming stable release.

  • Let the platform operator integrate the Release Candidate version with the current automation in place to ship a9s Data Service versions. This way everything is in place to change to the Stable stage more quickly.

Stable

The stage Stable for an a9s Data Service version means the features provided by the service are production ready. Once a service is marked as Stable, a9s will provide End-of-life information.

Example

The PostgreSQL developers release a preview version for PostgreSQL, let’s say version 11. Initial support for PostgreSQL 11 gets developed and released as Beta. The product matures with every upstream release before the final release. All major versions can be deactivated by platform administrators.

Once PostgreSQL 11 is officially released upstream, a9s aims to create a Release Candidate for that upstream version x days later.

After a while the version gets marked as stable and End-of-life information get released.