• File Bug
• View source
• Edit this page

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: theyallow users to create resources that run on or expose the external software insome 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 eventuallyneed to address the fact that all of these types of software have releaselifecycles, and the versions they currently expose will eventually reachend-of-life.

Guidance

Services that expose external software dependenciesshould allow users tocreate resources using any currently-supported LTS (long-term support) versionof the supported software, andmay allow users to create resources usingnon-LTS versions.

Servicesshould not indefinitely allow users to create new resources usingversions that have reached end-of-life, although theymay have a transitionperiod between when the software version reaches end-of-life and when supportfor creating new resources with that version is removed.

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

If possible, servicesshould allow previously-created resources to remain,andmay warn users of the risks associated with continuing to useend-of-life software. Servicesshould not proactively remove resourcesusing 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 businessreasons (usually because the end-of-life software still has significantadoption), the servicemay choose to officially support the end-of-lifeversion, butmust take on the responsibility of patching and maintainingthe software if it does so.