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

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

Изображение выпуска релизов

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

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

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.

Организация разработки#

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

Внимание

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

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

Фактический релиз

Пример фактического релиза модуля gtk

Если вы видите в Support, что на задаче стоит версия с постфиксом dev, значит она попадёт в release через один понедельник.
Иначе, если версия с постфиксом rc, то в release будет в следующий понедельник.
Если же постфиксов нет, то задача уже находится в release под соответствующим тегом.

Содержание