This AIP is currently under review. This means that the editors have read it and are in high-level concurrence, and while it is not yet fully approved, we have a good faith expectation that the AIP will be approved in something close to its current state.

AIP-182

External software dependencies

Some services have a particular type of dependency on external software: they allow users to create resources that run on or expose the external software in some way. For example:

  • A database admin service can allow users to create databases running on a particular version of a particular database engine (for example, PostgreSQL 13.4).
  • A virtual machine service can allow users to create VMs running a particular operating system (for example, Ubuntu 20.04).
  • An application or function platform service can allow users to write code that runs against a particular version of a programming language (for example, Node.js 16.6).

Services that provide external software to users in this way will eventually need to address the fact that all of these types of software have release lifecycles, and the versions they currently expose will eventually reach end-of-life.

Guidance

Services that expose external software dependencies should allow users to create resources using any currently-supported LTS (long-term support) version of the supported software, and may allow users to create resources using non-LTS versions.

Services should not indefinitely allow users to create new resources using versions that have reached end-of-life, although they may have a transition period between when the software version reaches end-of-life and when support for creating new resources with that version is removed.

Note: Restricting or removing the ability to create resources using end-of-life versions of software is not considered a breaking change for the service for the purpose of AIP-181, even though it actually is one. However, because the change can break existing users' workflows, services must notify users who are using resources approaching end-of-life.

If possible, services should allow previously-created resources to remain, and may warn users of the risks associated with continuing to use end-of-life software. Services should not proactively remove resources using end-of-life software, or impose other restrictions on existing resources, unless critical security concerns require the service to do so.

Continued support

If supporting a version that has reached end-of-life is necessary for business reasons (usually because the end-of-life software still has significant adoption), the service may choose to officially support the end-of-life version, but must take on the responsibility of patching and maintaining the software if it does so.