Акты Становления

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

Набор правил, которые определяют, какая версия Идеи будет показана в определённой ситуации. Видимость зависит от истории версий Идеи, её веток и того, как её запрашивают.

Чтобы система развивающихся, связанных друг с другом Идей была полезной, нужен ясный и предсказуемый способ определять, какая версия Идеи видна в каждом конкретном случае. В этом документе мы рассмотрим модель, управляющую видимостью. Она состоит из двух частей: системы версий, которая создаёт разные состояния Идеи, и механизма выбора, который решает, какое из состояний показать.

Управление версиями: Создание состояний для показа

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

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

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

mainfeature-x1.11.21.2.feature-x.11.2.feature-x.21.2.feature-x.31.3

Правила изменения версий:

  • Совместимые изменения: Небольшие правки, после которых новая версия может полностью заменить старую. Например, изменение описания или добавление нового поля в схему. Такие изменения создают новую минорную ревизию (например, 1.2 становится 1.2.1).
  • Несовместимые (ломающие) изменения: Изменения, после которых новая версия не может заменить старую. Обычно это удаление или изменение существующих полей в схеме. Такие изменения требуют повышения основной версии (например, 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: — это конкретный язык, который используется для запроса нужного вида и путешествий по этому богатому миру версий и веток.