Skip to content

♻️ Процесс версионности в U.L.I.

Этот документ объясняет, как в U.L.I. понимается и применяется версионность проектов.

Он не описывает версионность документов Knowledge Substrate. Для документов используются отдельные документы Management Layer: Versioning Standard и ♻️ Процесс версионности.

В U.L.I. версия проекта фиксирует не просто набор изменений, а новое устойчивое состояние проекта, репозитория или продукта.

1. Версия как состояние проекта

Версия проекта означает, что завершён целостный логический этап развития.

Она фиксирует:

  • какое новое состояние достигнуто;
  • какие возможности, исправления или архитектурные изменения вошли в этот этап;
  • какой ресурс или вклад проект начал давать экосистеме сильнее, чем раньше.

Версия не повышается автоматически из-за количества PR, закрытых задач или прошедшего времени. Повышение версии — это решение о зрелости состояния.

2. Связь с производственным циклом

В производственном цикле проекта версия появляется после прохождения этапов:

Project Intent -> Work Model Planning -> Implementation -> Release Fixation

На этапах Work Model Planning и Implementation работа структурируется и выполняется через Epic Issue, Work Package, branch и PR.

На этапе Release Fixation проверяется, можно ли признать результат новой версией.

Только после успешной Release Fixation версия фиксируется через Git tag, GitHub Release, release summary и связанные материалы, если они применимы к проекту.

3. Семантика версий

Типичная логика:

  • v0.1, v0.2, v0.x — проект находится в стадии формирования и может оставаться внутренним или предварительным, хотя уже проходит завершённые циклы развития;
  • v1.0 — проект признан стабильным и готовым к публичной ответственности либо к устойчивому внутреннему использованию;
  • v1.x и выше — развитие стабильного проекта через новые возможности, улучшения, исправления и архитектурные усиления.

Переход к v1.0 не требует прохождения всех промежуточных значений до v0.9.

4. Версия проекта и статус продукта

В технологическом контуре один репозиторий соответствует одному проекту. Версия относится прежде всего к проекту и не определяет его рыночный тип автоматически.

  • Внутренний инфраструктурный или технический проект может иметь стабильную v1.0 и не становиться внешним продуктом.
  • Репозиторный проект становится продуктом в точке публичного v1.0, если у него одновременно определены аудитория, ценностная значимость, доступ, владелец поддержки и показатели наблюдения.
  • После перехода в продукт репозиторий остаётся проектом разработки. Публичная версия поддерживается в production-контуре, а следующая версия развивается новым циклом и после Release Fixation обновляет продукт.

Таким образом, v1.0 — необходимый технический порог для репозиторного продукта, но не достаточное основание назвать продуктом любой репозиторий.

5. Когда повышается версия

Версия повышается, когда завершён новый логический этап и результат прошёл Release Fixation Standard.

Примеры оснований:

  • завершена базовая архитектура проекта;
  • закрыт важный Epic Issue;
  • появился новый устойчивый пользовательский сценарий;
  • проект стал выполнять ключевую функцию;
  • устранён критический разрыв, который раньше мешал стабильности;
  • проект начал приносить новый или усиленный ресурс экосистеме.

6. Release Fixation

Release Fixation — это стандартный gate перед признанием новой версии.

Он отвечает на вопрос: можно ли действительно считать текущее состояние проекта новой устойчивой версией?

Подробные правила описаны в Release Fixation Standard.

7. Где фиксируется версия

В проектах U.L.I. версия обычно фиксируется через:

  • Git tag;
  • GitHub Release;
  • release summary;
  • README, release notes, если они используются в проекте.

8. Версия, стратегия и ресурсы

Новая версия проекта формируется на пересечении внутренней логики развития самого проекта и текущего направления развития экосистемы.

Новая версия проекта должна быть связана с тем, какой ресурс экосистемы она усиливает: продуктовый, технический, инфраструктурный, образовательный, управленческий или иной.

9. Практический принцип

Версия в U.L.I. — это не просто число. Она означает завершение этапа развития, признание нового устойчивого состояния и точку, от которой можно строить следующий цикл.

Для проектов и репозиториев применяется двухуровневая модель:

MAJOR.MINOR

Примеры:

0.1
1.0

Здесь версия отражает завершённый логический этап развития проекта.

Повышение версии происходит только после завершения запланированного этапа, а не в процессе работы. В этот момент создаётся Git-тег, публикуется Release в GitHub, фиксируется завершение Epic Issue.

Версия в данном случае — это одновременно:

  • 🧠 управленческое решение;
  • 🤝 коммуникационный сигнал команде;
  • 🔒 техническая фиксация состояния системы.

Связанные документы