apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
    name: foo
---
apiVersion: core.oam.dev/v1alpha2
kind: Trait
metadata:
    name: foo

apiVersion: one.dev/v1alpha2
kind: Component
metadata:
    name: foo
---
apiVersion: other.dev/v1alpha2
kind: Component
metadata:
    name: foo

apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
    name: foo
---
apiVersion: core.oam.dev/v1
kind: Component
metadata:
    name: foo

metadata:
  name: alpine-task
  labels:
    app: my-app-v1  # Не нормативный пример
  annotations: **Версия: «1.0.1»**

**Описание**: Задача, поддерживаемая файловой системой Alpine Linux.

Раздел метаданных используется во всех схемах. Он также совместим с разделом метаданных Kubernetes. Обратите внимание, однако, что метаданные Kubernetes являются надмножеством метаданных OAM и содержат атрибуты, которые OAM не распознаёт.

## Группа, версия и вид

Многие API-объекты, описанные в этом документе, используют схему именования, называемую «Группа, Версия, Вид». Эта схема, популяризированная Kubernetes, обеспечивает последовательный способ пространства имён и управления версиями API-объектов и используется здесь для управления версиями объектов OAM API.

В этом разделе описывается схема.

### Группа

Группа — это пространство имён для сбора нескольких связанных видов. Группы используют соглашение об именах DNS. Примерами групп являются:

* components.oam.dev;
* functions.azure.com;
* my.dev.

Все группы в домене oam.dev считаются зарезервированными для объектов OAM. И все объекты, указанные здесь, принадлежат группам в этом домене.

Группа ДОЛЖНА быть уникальной в глобальном масштабе.

### Версия

Строка версии — это версия API. Следуя общей парадигме, API-интерфейсы версионируются только по основному номеру. Второстепенные и патч-номера опущены из версий API. Фактические второстепенные и патч-версии базовых механизмов могут повторяться, но они ДОЛЖНЫ повторять эту версию при любом критическом изменении. Другими словами, основной номер служит гарантией совместимости, и второстепенные и патч-числа не должны изменять эту гарантию. Поэтому потребители API не могут указать более тонкую детализацию, чем основная версия.

Номер версии API всегда начинается с префикса v, за которым следуют одна или несколько цифр.

Примеры:

* v1;
* v2;
* v973.

Есть два дополнительных модификатора, которые являются частью основного номера версии:

1. alphaN (где N — одна или несколько цифр) указывает, что эта функция является экспериментальной и может быть удалена, но её текущий маркер совместимости равен 1.
2. betaN (где N — одна или несколько цифр), указывает, что эта функция ещё не стабильна. N является маркером совместимости.

Версии API, помеченные как alpha или beta, считаются нестабильными и подвержены критическим изменениям.

Можно применять только один из двух модификаторов одновременно:

* v1alpha1;
* v973beta231.

Совместимость устанавливается только точным соответствием. v1 не считается совместимым с v2, v1alpha1 или v1beta2.

У версий нет требования уникальности.

### Вид

Вид — это имя типа. Например, вид компонента — Component, а вид признака — Trait. Виды всегда состоят из слов, где первая буква заглавная, а первая буква каждого слова заглавная. Виды ДОЛЖНЫ использовать заглавные буквы для каждого символа аббревиатуры (например, HTTP, а не Http).

Виды ДОЛЖНЫ быть уникальными в пределах группы.

### Представления группы/версии/вида

Полное представление группы/версии/вида — GROUP/VERSION.KIND. Вот несколько примеров:

* local.dev/v7alpha2.Proxy;
* cache.example.com/v1.Redis;
* azure.com/v2.Functions.

На схемах группа и версия представлены в одном поле, а вид — в другом:

```yaml
apiVersion: local.dev/v7alpha2
kind: Proxy

Proxies.local.dev # разрешено, но не рекомендуется