Skip to content

Version Rules

Управление версиями проекта: Документация для команды

Общая схема версий:

Мы будем использовать версионную схему X.Y.Z, где:

X — Релизная версия: это стабильная версия продукта, которая готова к использованию. Она отражает основные этапы выпуска.

Y — Добавление новых фич (Features): увеличиваем, когда вносятся новые возможности или улучшения в продукт.

Z — Исправления ошибок (Bug Fixes): увеличиваем, когда исправляются баги или улучшаются стабильность системы.

Принципы работы с версиями:

  1. X (Релизная версия):

X представляет собой основную версию проекта, которая считается стабильной и готовой для использования.

X увеличивается, когда происходит существенное обновление или переработка системы. Например, когда фронтенд и бэкенд меняются настолько, что требуется новое большое обновление, мы увеличиваем X.

Пример: 2.0.0, 3.0.0.

  1. Y (Новые фичи):

Y увеличивается, когда в проекте добавляются новые фичи или функциональность.

Это может включать добавление новых функций как на стороне фронтенда, так и на бэкенде. Основное — это не ломать существующую функциональность.

Пример: 1.1.0, 1.2.0.

  1. Z (Багфиксы):

Z увеличивается при исправлении ошибок или улучшении стабильности системы.

Это может включать исправление багов, улучшение производительности, или небольшие изменения, не затрагивающие основные функции.

Пример: 1.1.1, 1.2.1.

Пример версий:

  1. Версия 1.0.0 — Начальный релиз проекта, когда продукт стабилен и готов для использования.

  2. Версия 1.1.0 — Внесены новые фичи, например, добавлены новые возможности в frontend или backend.

  3. Версия 1.1.1 — Исправлены баги или улучшена производительность, но не добавлены новые фичи.

  4. Версия 1.2.0 — Добавлены новые фичи или функциональности, например, интеграция с новым API или улучшения UI.

  5. Версия 2.0.0 — Существенные изменения или улучшения в проекте, требующие нового релиза. Может быть переработана структура API или добавлены новые ключевые фичи.

Как работать с версиями:

  1. Когда и как увеличивать X, Y и Z:

X увеличиваем при больших обновлениях, изменениях архитектуры или появлении новых ключевых возможностей.

Y увеличиваем при добавлении новых фич, функциональных улучшений или изменений, которые не ломают совместимость с предыдущими версиями.

Z увеличиваем при исправлении багов, улучшении производительности или других мелких улучшениях.

  1. Кому и когда делать коммиты для увеличения версии:

Каждый коммит, который добавляет новые фичи, должен учитывать увеличение Y версии.

Каждый коммит, исправляющий баги или улучшая стабильность, должен увеличивать Z версию.

Когда вы работаете над большим обновлением или изменением, влияющим на архитектуру, не забывайте увеличивать X.

  1. Советы для правильного обновления версии:

Не забывайте проверять текущую версию проекта перед каждым изменением, чтобы понять, когда нужно обновить X, Y или Z.

При добавлении функциональности или исправлении ошибок обязательно следите за совместимостью версий frontend и backend, чтобы они были согласованы.

Общие рекомендации:

Держите версии синхронизированными, если работаете над крупным обновлением, чтобы избежать несоответствий в версиях между frontend и backend.

Если изменения в одном компоненте не затрагивают другой, можно обновить версии компонентов отдельно, при этом следуя общему подходу.

Обязательно документируйте все изменения, которые могут повлиять на совместимость версий или которые требуют увеличения мажорной версии.

  1. Пример коммитов:
sh
git commit -m "feat: добавлен новый функционал"
git commit -m "fix: исправлена ошибка"
git commit -m "release: версия X обновлена"
npm run release