109: Концепция/Версионирование
- Требует:
- Открывает возможности для:
Схема версионирования, в которой версии представляют собой идентификаторы, разделенные точками (например, 1.2.feature-x.3
), объединяющая концепции линейных релизов, веток и черновиков в единую иерархическую структуру.
Любая развивающаяся система сталкивается с двумя основными проблемами: управлением изменениями (версионирование) и обеспечением параллельной работы (ветвление). Этот документ описывает единую модель, в которой эти две концепции тесно переплетены, создавая безопасную и гибкую среду для разработки и экспериментов.
Анатомия идентичности: Иерархические версии
Идентичность Идеи в этой продвинутой модели состоит из ее path
(текстового идентификатора, например articles/common/button
) и ее version
. Версия — это не просто число, а богатая, разделенная точками иерархия, которая рассказывает историю эволюции Идеи. Полностью определенная идентичность также включает домен (например, my-project.com
), который устанавливает суверенное пространство имен, где находится путь.
Например, версия вроде 1.2.feature-x.3
говорит нам, что это третья ревизия ветки feature-x
, созданной из версии 1.2
. Эта структура элегантно сочетает традиционное версионирование с возможностями ветвления.
Версия — это иерархический идентификатор, такой как
1.2.feature-x.3
, который отражает происхождение и состояние Идеи.
Анатомия видимости: Ветки и пути поиска
В то время как версия представляет состояние и историю Идеи, модель ветвления определяет, где и как ее можно увидеть. Это работает через две взаимодополняющие концепции: Ветки и Путь поиска.
Ветки: «Где»
Каждая версия Идеи в базе данных связана с одной или несколькими Ветками (например, ["main", "feature/new-billing"]
). Эти ветки действуют как каналы, контролирующие видимость. Идея видна пользователю или процессу только в том случае, если она опубликована хотя бы в одной из веток, включенных в путь поиска их запроса.
Путь поиска: «Как»
Настоящая мощь системы заключается в Пути поиска. Это упорядоченный список имен веток, который указывает резолверу, где искать Идею и в каком порядке приоритета. Типичный путь поиска во время разработки может выглядеть так: ['feature/my-new-idea', 'staging', 'main']
Эта конфигурация создает каскадную систему наложения:
- Сначала ищем Идею, опубликованную в ветке
feature/my-new-idea
. - Если не найдено, ищем в ветке
staging
. - Наконец, возвращаемся к Идее, опубликованной в ветке
main
.
Это позволяет разработчику видеть полное, функциональное окружение, состоящее из его конкретных изменений, наложенных поверх общей, стабильной системы, без необходимости дублировать каждую Идею.
Видимость контролируется ветками, которые определяют, где видна Идея. Путь поиска (
['feature-x', 'main']
) — это приоритезированный список, который указывает резолверу, где и в каком порядке искать. Это создает бесшовное наложение, показывая работу в ветке поверх стабильной системы.
Эволюция версий
Версии состоят из ревизий, которые могут быть целочисленными ревизиями для последовательных публичных версий (например, 1.2
) или ревизиями веток для именованных линий разработки (например, feature-x
). Они развиваются двумя основными способами:
- Совместимые изменения: Неломающее изменение создает новую минорную ревизию (например,
1.2
становится1.2.1
). - Несовместимые изменения: Ломающее изменение должно «подняться» на более высокий уровень иерархии версий. Изменение, нарушающее совместимость с
1.2
, создаст новую версию1.3
. Система автоматически обнаруживает эти несовместимости, анализируя изменения схемы, гарантируя, что номера версий точно отражают истинные границы совместимости без ручных догадок.