108: Концепция/Видимость

Чтобы система развивающихся, взаимосвязанных Идей была полезной, должен существовать ясный и предсказуемый способ определять, какая версия Идеи видна — или видима — в любом заданном контексте. Этот документ описывает двухчастную модель, управляющую видимостью: систему версионирования, которая создает возможные состояния Идеи, и механизм выбора, который определяет, какое состояние становится видимым.

Версионирование: Создание состояний для отображения

Прежде чем выбрать версию, она должна существовать. Иерархическое Версионирование — это механизм для создания и отслеживания различных состояний Идеи с течением времени. Версия — это не просто число, а сложная, разделенная точками иерархия, которая рассказывает историю эволюции Идеи.

Версии состоят из целочисленных ревизий для последовательных публичных выпусков (например, 1.2) и ревизий в ветках для именованных линий разработки (например, feature-x). Например, версия вроде 1.2.feature-x.3 говорит нам, что это третья ревизия ветки feature-x, созданной из версии 1.2.

Правила эволюции версии:

• Совместимые изменения: Неломающее редактирование, при котором новую версию можно безопасно использовать как полную замену старой. Примеры включают изменение данных context или solution, или добавление нового поля в schema. Такие изменения создают новую минорную ревизию (например, 1.2 становится 1.2.1).
• Ломающие изменения: Изменение, при котором новую версию нельзя использовать как замену старой. Обычно это связано с удалением или изменением существующих полей в schema. Эти изменения должны "подниматься" на более высокий уровень иерархии версий (например, изменение, нарушающее совместимость с 1.2, создаст 1.3). Система может автоматически обнаруживать ломающие изменения на основе схемы.

Выбор: Определение видимого состояния

При наличии богатой истории версий необходим механизм выбора для определения правильной. Это достигается за счет четкого разделения между тем, как Идея публикуется, и тем, как она извлекается. Процесс имеет два измерения извлечения: пространственное (в каких разделах искать) и временное (на какой момент времени).

Ветки: Публикация и разделение

Например, каждая версия Идеи в базе данных связана с одной или несколькими ветками, например, ["main", "feature/new-billing"]. Этот акт публикации делает Идею доступной в этих конкретных разделах, обеспечивая безопасный рабочий процесс.

Это дает два фундаментальных преимущества:

• Изоляция: Работа над новой функцией (например, в ветке feature/new-billing) не мешает стабильной ветке main. Это предотвращает влияние незавершенной или содержащей ошибки работы на производственные системы.
• Экспериментирование: Ветки легко и дешево создавать. Это поощряет эксперименты, позволяя разработчикам отбрасывать ветку, если эксперимент не удался, без какого-либо влияния на основную систему.

Путь Поиска: Приоритетное извлечение

Этот механизм извлечения является ключевым для рабочего процесса разработки и отвечает на пространственный вопрос. Например, типичный путь поиска разработчика может быть установлен как ['feature/my-new-idea', 'staging', 'main'].

Эта конфигурация создает каскадную систему наложения для извлечения:

1. Сначала ищем соответствующую Идею в разделе feature/my-new-idea.
2. Если не найдено, ищем в разделе staging.
3. Наконец, ищем в разделе main.

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

Время Отсечки: Временное извлечение

Второе измерение извлечения — временное. Каждый запрос на разрешение выполняется относительно состояния системы, существовавшего в определенный момент. Это контролируется Временем Отсечки.

Если время отсечки не указано, оно по умолчанию равно текущему времени (now()), извлекая самые последние видимые версии. Однако, указав временную метку из прошлого, вы можете выполнить "запрос в прошлое". Это указывает резолверу найти версию Идеи — и все ее зависимости — которая была последней согласно пути поиска на тот самый момент. Эта возможность является технической основой для идеальной воспроизводимости.

От модели к применению

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

Следующий документ, 109: Концепция/Адресация, представляет схему URI idea: — конкретный синтаксис, используемый для запроса определенного представления и навигации по этой богатой, версионированной и разветвленной реальности.