Перейти к основному содержанию
`Ctrl`+`K`

# Выпуск релизов ядровых модулей

## Версионирование релизов

Версия состоит из пяти разрядов, где последний не является обязательным:

`generation.major.minor.build.patch`.

Версии формируются по следующим правилам:

- `Поколение` — крупные изменения, которые ломают обратную совместимость. Старшая версия может означать полное переписывание кода. В этом типе релиза происходит очистка миграционных скриптов предыдущей версии.Устанавливается только на предыдущее поколение.

- `Мажор` — крупные изменения, которые могут ломать обратную совместимость. К примеру, переключение сервера приложений или обновление SBT плагина.

- `Минор` — плановые изменения в рамках развития модуля, изменение конфигурации модулей проекта (добавление, удаление модулей).

- `Билд` — сквозная нумерация. Увеличивается при выпуске любой из версий, не считая патчей.

- `Патч` — изменения критических ошибок на уже выпущенных версиях. От патчей нельзя создавать другие версии, кроме последующих патчей.

Пример обычной версии: `1.4.25.612`.

Пример версии с патчем: `1.4.25.612.1`.

## Управление задачами через релизы в Support

Билд-версии не учитываются, так как являются сквозными и увеличиваются вместе с любой другой версией, не считая патча.

Для удобства наименования в примерах разряды будут помечаться:

- `Поколение [Generation]` - `X`.

- `Мажор [Major]` - `Y`.

- `Минор [Minor]` - `Z`.

`Релизы в Support` используются для отслеживания состояния функциональности:

- `X.Y.Z-dev` - задача находится в разработке (ветка `main`).

- `X.Y.Z-rc` - задача в кандидате на релиз (ветка `release-candidate`).

- `X.Y.Z` - задача выпущена в стабильной версии (ветка `release`).

## Процесс выпуска релизов

Выпуск релизов происходит еженедельно, каждый понедельник в 16:00.

1. Слияние `release-candidate` в `release`. После слияния, `релиз в Support` `X.Y.Z-rc` переименовывается в `X.Y.Z`.

2. Слияние `main` в `release-candidate`. После слияния, `релиз в Support` `X.Y.Z-dev` переименовывается в `X.Y.Z-rc`. Создаётся новый тег задач `X.Y.(Z + 1)-dev`.

После слияния веток выпускаются релизы модулей.

Внимание

Релизы в Support относятся к задачам в менеджере задач и не являются git-тегами, не считая `release` ветки.

### Примеры жизненного цикла версии

1. Начало разработки версии 1.0.2:

   - Ветка `main`: `1.0.2-dev`.

   - Ветка `release-candidate`: `1.0.1-rc`.

   - Ветка `release`: `1.0.0`.

2. После слияния `release-candidate` в `release`:

   - Ветка `main`: `1.0.2-dev`.

   - Ветка `release-candidate`: `1.0.2-rc`.

   - Ветка `release`: `1.0.1` (бывшая `1.0.2-rc`).

3. После слияния `main` в `release-candidate`:

   - Ветка `main`: `1.0.3-dev` (новая версия для разработки).

   - Ветка `release-candidate`: `1.0.2-rc` (бывшая `1.0.2-dev`, автоматически переименовывается в `Support` при выпуске релизов).

   - Ветка `release`: `1.0.1`.

## Организация разработки ядровых модулей

После выполнения задачи и создания MR, необходимо установить тег к задаче, к примеру `1.0.3-dev`. По мере слияния веток и выпуска релизов, он будет переименован и в конечном итоге станет `1.0.3`. Все смогут отслеживать, когда и в каком релизе будет выпущена задача.

Внимание

При необходимости `черри-пикать` ваш код в ветки `release-candidate` или `release`, необходимо указывать корректные версии в релизах к задаче.

Релиз выставляется в поле фактический релиз:

Если вы видите в `Support`, что на задаче стоит версия:

- С постфиксом `dev` - значит она попадёт в `release` через один понедельник.

- С постфиксом `rc` - значит она попадёт в `release` в следующий понедельник.

- Если же постфиксов нет, то задача уже находится в `release` под соответствующим тегом.

## Организация разработки прикладных модулей

При разработке прикладных модулей, таких как `asf`, в качестве зависимостей должны использоваться стабильные версии ядровых модулей `gtk`, `btk` или ветку `release`. Использование веток `main` или `release-candidate` для ядровых модулей в процессе разработки прикладной функциональности не допускается, так как они могут содержать непротестированный или нестабильный код.

## Разработка кросс-модульных функциональностей

Если реализация задачи затрагивает как ядровой, так и прикладной модули, требуется соблюдение следующих правил:

- Обеспечение обратной совместимости: Все изменения в публичном API ядрового модуля должны сохранять обратную совместимость с текущей стабильной версией (`release`). Это гарантирует, что обновлённый прикладной модуль будет корректно работать как со старой, так и с новой версией ядра на период перехода.

- Порядок слияния изменений:

  1. Изменения в ядровой модуль должны быть приняты и доведены до стабильной ветки `release` через стандартный процесс релизов.

  2. Только после п1 допускается снятие статуса Draft с MR в прикладной модуль и продолжение процесса его слияния.