DRAFT -  DRAFT -  DRAFT -  DRAFT -  DRAFT -  DRAFT - 

Extensions are always interpreted in relation to a version of the core API. In other words, from a client's perspective, an extension modifies a particular version of the core API in some way. In reality, an extension may be applicable to several versions of an API at once. For example, a particular extension may continue to be available as a core API moves from one version to another. In fact, different implementations may decide to include support for an extension at different versions. As explained in , when an extension is defined, the minimal version of the core API that is required to run the extension is specified; implementers are free to support the extension in that version or in a later version of the core. Note, however, that because the extension mechanism allows for promotion, an extension in one version of a core API may become a standard feature in a later version.

[Note]Note

As always, implementers are not required to support an extension unless it is promoted to the core.

Because several versions of the core API may be supported simultaneously, and because each version may offer support for a different set of extensions, clients must be able to detect what versions and extensions are available in a particular deployment. Thus, both extensions and versions are queryable. Issuing a GET on the base URL (/) of the API endpoint returns information about what versions are available. Similarly, issuing a GET on the API's extensions resource (/v1.1/extensions) returns information about what extensions are available. (See for details of such requests.) Note that, since extensions modify a particular version of the API, the extensions resource itself is always accessed at a particular version.

Backward-compatible changes in an API usually require a minor version bump. In an extensible API, however, these changes can be brought in as extensions. The net effect is that versions change infrequently and thus provide a stable platform on which to develop. The Policy Review Board (PRB), with the help of project team leaders, is responsible for ensuring that this stability is maintained by closely guarding core API versions. Extensions, however, can be developed without the consent or approval of the PRB. They can be developed in a completely decentralized manner both by individual OpenStack developers and by commercial vendors. Because extensions can be promoted to standard features, the development of new versions can be influenced significantly by individual developers and the OpenStack client community and is therefore not strictly defined by the PRB. In other words, new features of a core API may be developed in a bottom-up fashion.

That said, not all extensions are destined to be promoted to the next API version. Core APIs always deals with core functionality — functionality that is supported by all implementations and is applicable in common cases. Extensions that deal with niche functionality should always remain extensions.

The table below summarizes the differences between versions and extensions.