Управление релизами

Канонические правила версионирования и выпуска продукта.

Источник истины версии

• Файл VERSION в корне репозитория.
• Git tag формата vX.Y.Z.
• CHANGELOG.md в формате Keep a Changelog.

Все три артефакта должны быть согласованы.

Политика версионирования

Используется SemVer:

• MAJOR — breaking change в пользовательских контрактах или критичных интеграциях.
• MINOR — новая функциональность без breaking change.
• PATCH — исправления и безопасные внутренние изменения без нового поведения контракта.

До 1.0.0 допускается более быстрый темп изменений, но breaking changes всё равно обязаны фиксироваться явно в changelog и ADR/схемах.

Политика changelog

• CHANGELOG.md ведётся по Keep a Changelog.
• Есть секция Unreleased.
• Пользовательски значимые изменения обязаны попадать в changelog в момент разработки, а не задним числом.
• История релизов хранится в changelog, а не в versioned копиях документации.

Политика коммитов

Для автоматизации release notes используются Conventional Commits:

• feat
• fix
• refactor
• docs
• ci
• build
• test
• chore

Процесс релиза

1. Обновить документацию и схемы в том же MR, что и код.
2. Актуализировать CHANGELOG.md (Unreleased).
3. Перед релизом установить новую версию в VERSION.
4. Зафиксировать release section в CHANGELOG.md.
5. Создать git tag vX.Y.Z.
6. GitLab tag pipeline валидирует версию, генерирует release notes и создаёт GitLab Release.

Что не делаем

• Не ведём параллельные changelog-файлы по сервисам без отдельного ADR.
• Не храним README-v2.md, release-notes-final.md и прочие versioned документы.
• Не считаем git tag достаточным без обновлённых VERSION и CHANGELOG.md.

Связано

• gitlab-cicd.md
• documentation-standard.md
• ../20-architecture/principles.md