1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Files
openshift-docs/modules/api-support-tiers.adoc
2022-01-12 20:03:00 +00:00

33 lines
2.3 KiB
Plaintext

// Module included in the following assemblies:
//
// * rest_api/understanding-api-support-tiers.adoc
[id="api-tiers_{context}"]
= API tiers
All commercially supported APIs, components, and features are associated under one of the following support levels:
[discrete]
[id="api-tier-1_{context}"]
== API tier 1
APIs and application operating environments (AOEs) are stable within a major release for a minimum of 12 months or 3 minor releases from the announcement of deprecation, whichever is longer. The release that introduces a new or revised API or AOE, and the two following minor releases (n, n+1, n+2).
[discrete]
[id="api-tier-2_{context}"]
== API tier 2
APIs and AOEs are stable within a major release for a minimum of 9 months or 3 minor releases from the announcement of deprecation, whichever is longer.
[discrete]
[id="api-tier-3_{context}"]
== API tier 3
This level applies to languages, tools, applications, and optional Operators included with {product-title} through Operator Hub. Each component will specify a lifetime during which the API and AOE will be supported. Newer versions of language runtime specific components will attempt to be as API and AOE compatible from minor version to minor version as possible. Minor version to minor version compatibility is not guaranteed, however.
Components and developer tools that receive continuous updates through the Operator Hub, referred to as Operators and operands, should be considered API tier 3. Developers should use caution and understand how these components may change with each minor release. Users are encouraged to consult the compatibility guidelines documented by the component.
[discrete]
[id="api-tier-4_{context}"]
== API tier 4
No compatibility is provided. API and AOE can change at any point. These capabilities should not be used by applications needing long-term support.
It is common practice for Operators to use custom resource definitions (CRDs) internally to accomplish a task. These objects are not meant for use by actors external to the Operator and are intended to be hidden. If any CRD is not meant for use by actors external to the Operator, the `operators.operatorframework.io/internal-objects` annotation in the Operators `ClusterServiceVersion` (CSV) must be specified, and that signals that the corresponding resource is internal use only.