Для наших релизов мы придерживаемся версионирования основанного на Semver spec.

MAJOR

Содержит значительные новые функции и изменения, возможно, включает несовместимые изменения. Обновление требует усилий со стороны разработчиков и включает изменения, несовместимые с предыдущими версиями, в API, путях к файлам, поведении компонентов и/или зависимостях. Ранее объявленные устаревшими компоненты удаляются при переходе на новую мажорную версию.

Например,

• Изменяется наименование экспортируемых точек входа;
• Изменяется или переименовывается public interfaces (@Inputs/@Outputs);
• Изменяется CSS, которые затрагивают стили вне компонента;
• Обновляется major у peer dependencies;
• Визуальное изменение в компонентах, которое может повлиять на общедоступный API.

MINOR

Включает в себя небольшие функциональные возможности и изменения. Обновление не требует вмешательства разработчиков. Минорные версии могут содержать компоненты, которые объявляются устаревшими. Обеспечивается полная обратная совместимость.

Например,

• Что-либо добавляется в Template(). Это включает элементы, атрибуты и классы.

PATCH

Содержит исправления ошибок. Обновление не требует усилий разработчиков.

Например,

• обновлены зависимости пакетов;
• изменения в структуре проекта;
• имеются доработки / исправления.

Без релиза

• Обновлены dev dependencies
• Добавлены тесты или примеры
• Обновлены примеры
• Обновлена внутренняя документация

Мы следуем графику временных релизов, который состоит из:

• Одного мажорного релиза каждые шесть месяцев
• От одного до трёх минорных релизов для каждого мажорного релиза
• Патч-релизы выпускаются в качестве горячих исправлений при необходимости

Все мажорные релизы поддерживаются примерно 12 месяцев. Мы различаем два этапа поддержки для мажорных релизов:

Наша политика поддержки распространяется на все компоненты системы дизайна, включая кодовую базу, наборы дизайна в Figma и нашу документацию.

Мы рекомендуем всегда следовать активной версии. Когда версия переходит с активной стадии на стадию LTS (долгосрочной поддержки), проекты должны начать миграцию на новую активную мажорную версию. При этом мы всегда готовы рассматривать критичные исправления и для более ранних версий.