Релизы

Есть два вида релизов, и у них одинаковая форма — оба выпускают весь флот сразу, под одной версией:

• Минорный релиз режется из master и открывает новую линию X.Y.
• Патч-релиз режется из патч-ветки этой линии (X.Y.x) и переводит весь флот на X.Y.Z.

Разумеется, у нас будет и установленная процедура Major релизов. Пока точной процедуры нет, но когда появится - мы её тоже задокументируем.

Про раскладку веток под всем этим — см. Модель ветвления.

Минорные релизы

Минорный релиз публикует каждый компонент вместе под одной версией X.Y.0 и помечает его тегом vX.Y.0 на master (см. одна версия для всех компонентов). Процедура, по порядку:

1. Housekeeping

Housekeeping это некий набор ручных правок, которые делаются перед релизом. Все они идут одним коммитом в master, чтобы весь релиз можно было чисто откатить или перенести (cherry-pick), если придётся его отложить.

• Задаём версию проекта Axelix. Между релизами axelixVersion в корневом gradle.properties несёт будущую версию с суффиксом -SNAPSHOT — например 3.1.0-SNAPSHOT, пока 3.1.0 находится в разработке. Housekeeping убирает суффикс, выставляя точную версию, которую мы выпускаем — для 3.1.0 ставим 3.1.0. Именно это значение читает релизный пайплайн, и по нему называется итоговый тег; выпустить -SNAPSHOT-версию пайплайн откажется. Корневой gradle.properties — единственное место, где живёт версия: каждый компонент флота наследует её оттуда.
• Обновляем версии в playground-ах. Примеры приложений под playgrounds/ по своей природе отдельные проекты — они не наследуют axelixVersion, а явно фиксируют версии стартеров и плагинов Axelix, которые используют. Поднимаем эти зафиксированные версии до выпускаемой.
• Обновляем документацию. Мы ведём версионированную документацию только по мажорным линиям. Пока минор в разработке, мы добавляем пометки «Upcoming Release Notice» для фич, которые он принесёт; когда мы выпускаем новый минорный релиз, эти пометки надо заменить на соответствующие «Released In» ноутисы.

2. Запускаем релизный пайплайн

Мы не создаём тег вручную. Релизный пайплайн читает версию из gradle.properties, прогоняет свои предрелизные проверки и только если всё зелёное — создаёт тег vX.Y.0 и публикует каждый компонент флота: как Maven-артефакты (стартеры и плагины), так и Docker-образ Master.

Патч-релизы

Патч-релиз, как и любой релиз Axelix, выпускает весь флот под одной версией — патчей по отдельным компонентам не существует. Процедура повторяет минорный релиз с одним структурным отличием: срез делается из патч-ветки минорной линии, а не из master. Шаг с документацией пропускается — патчи не меняют документацию.

1. Переключаемся на патч-ветку. Патч-работа живёт в единственной ветке линии с именем X.Y.x — маленький x обозначает всю патч-линию, и, в отличие от тега, имя ветки не несёт префикс v. Ветка ответвляется от тега vX.Y.0 этого минора (см. Модель ветвления → Где живёт патч-работа). Создаём её из тега, если это первый патч на этой линии; иначе она уже существует.

2. Доводим фиксы до этой ветки. Как правило, фикс сначала попадает в master, а затем бэкпортируется в патч-ветку; меняется только то, что патч на самом деле чинит.

3. Housekeeping в ветке (одним коммитом).

   • Задаём версию проекта Axelix. Ставим axelixVersion в корневом gradle.properties равным новой патч-версии X.Y.Z. В отличие от master, патч-ветка между релизами не несёт суффикс -SNAPSHOT — она просто остаётся на последней выпущенной версии своей линии, пока следующий патч её не поднимет.
   • Обновляем playground(-ы). Поднимаем playground-приложения до новой патч-версии — по той же причине, что и при минорном релизе: playground-ы фиксируют свои версии Axelix явно и не наследуют axelixVersion.

4. Запускаем релизный пайплайн. Это тот же пайплайн, что и для минорного релиза, только запущенный из патч-ветки, а не из master. Он прогоняет те же предрелизные проверки, публикует каждый компонент флота под X.Y.Z и создаёт общефлотовый тег vX.Y.Z. Как и любой тег Axelix, он несёт префикс v. Как и при минорном релизе, пайплайн создаёт тег, но не release notes — их разработчик пишет вручную для нового тега.

Разбор на примере

Допустим, релизу 3.1.0 нужен фикс в Axelix Spring Boot 3 Starter:

1. Патч живёт в ветке 3.1.x, ответвлённой от тега v3.1.0. Если линия 3.1 уже патчилась, ветка уже существует; иначе создаём её из v3.1.0.
2. Бэкпортируем фикс из master в эту ветку.
3. В корневом gradle.properties ставим axelixVersion равным 3.1.1 — патч-версии, которую хотим выпустить — и поднимаем playground-ы до 3.1.1.
4. Запускаем релизный пайплайн из ветки 3.1.x. Он создаёт общефлотовый тег v3.1.1 и публикует каждый компонент — стартеры, плагины и Master — под версией 3.1.1, хотя реально изменился только один стартер.

Результат — ровно то, что обещает раздел одна версия для всех компонентов: после среза 3.1.1 существует для всего флота. Обновлять ли вам каждый развёрнутый компонент сразу или только тот, что был реально исправлен — решать вам: совместимость гарантируется парой major.minor, так что расхождение на уровне патч-версии между развёрнутыми компонентами всегда безопасно.