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

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

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

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

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

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, необходимо указывать корректные версии в релизах к задаче.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Содержание