Версии и релизные зависимости
На этой странице собраны правила версионирования в Ecosystem54: как читать номер релиза, как проверять совместимость и что включать в release info.
Формат версии
Для большинства сервисов базовый номер версии записывается так:
compatibility.submodule.auth.service.
Если релиз является кандидатом, в конце добавляется постфикс rc.
6.17.12.4
6.17.12.4rccompatibility
Версия схемы совместимости релиза.
submodule
Версия экосистемного сабмодуля, под который собран релиз.
auth
Версия Auth-сервиса, с которой релиз должен быть совместим.
service
Собственная версия конкретного сервиса или приложения.
Как быстро читать номер версии
Сокращенные записи
Сокращенная запись используется там, где важна не полная версия сервиса, а только уровень совместимости компонента.
- сабмодуль:
6.17 - Auth-сервис:
6.17.12 - остальные сервисы:
6.17.12.4
Что означает rc
Постфикс rc означает release candidate.
Он показывает статус релиза, но не меняет его совместимость,
зависимости или структуру номера версии.
Главное правило чтения
При проверке релиза сначала сравнивайте compatibility,
затем submodule и auth.
Только после этого смотрите на собственную версию сервиса и наличие rc.
Back-end сервисы
Для back-end сервисов, кроме сабмодуля и Auth-сервиса, используется полная запись из четырех частей.
Пример: relay54 6.17.12.4.
- 6 - релиз относится к 6-й схеме совместимости
- 17 - сервис собран под 17-ю версию сабмодуля
- 12 - сервис должен работать с 12-й версией Auth-сервиса
- 4 - это собственная версия релиза сервиса
relay54
Запись 6.17.12.4rc читается так же, но означает, что перед вами не финальный релиз,
а release candidate.
Front-end сервисы
У front-end сервисов версия состоит из двух логических частей: версии самого продукта и списка обязательных back-end зависимостей, с которыми он должен поставляться.
W54 6.17.12.4rc-entity6.17.12.46.17.12.4rc- версия самого front-end сервисаentity6.17.12.4- обязательная зависимость от сервисаentityверсии6.17.12.4
Релизы приложений
Для приложений используется тот же принцип: сначала указывается версия самого приложения, затем - список дополнительных компонентов, которые обязаны входить в релизный комплект.
Ecosystem 6.17.12.4rc-appSub6.17.12.3
В примере выше 6.17.12.4rc - версия приложения, а appSub6.17.12.3 -
дополнительный компонент, который должен поставляться вместе с ним в указанной версии.
Что включать в release info
Release info должен кратко объяснять смысл конкретного релиза: что изменилось, зачем выпущен этот релиз и на что обратить внимание при его использовании. Это не полная документация по сервису, а короткое релизное описание.
Минимум для release info
- версию релиза
- краткое описание сути изменений в 2-5 строк
- ссылки на связанные материалы, если без них релиз нельзя проверить или запустить
Что важно в формулировке
- писать не список файлов, а смысл изменений
- указывать, что именно стало новым, измененным или обязательным для релиза
- если подробности большие, оставлять в release info короткое резюме и ссылку на нужный материал
Короткий пример
В релиз вошли изменения по унификации структуры экосистемных проектов и подготовке базы
для автоматизации деплоя. Закреплен единый подход к организации директорий, документации
и входных файлов проекта. Также проработан механизм автоматической генерации
README.md через manage.py и подготовлена docker-конфигурация
для локального запуска и дальнейшей автоматизации деплоя.
Самопроверка перед релизом
- ветка и тег названы корректно, а для кандидатов используется постфикс
rc - по номеру версии можно однозначно определить
compatibility, сабмодуль и Auth-сервис - для front-end или приложения перечислены все обязательные зависимости
- каждый обязательный раздел отражен в README или вынесен в отдельный файл
- если раздел временно пуст, это явно указано, а не пропущено
- если описание занимает больше 10 строк, на него дана ссылка в отдельном релизном файле