Кратко

  • recommended-min-version сравнивает только три числа: основную, дополнительную и исправляющую версии. Редакция 28 проекта YANG Semantic Versioning предписывает игнорировать _compatible, _non_compatible, а также метаданные предварительной сборки и сборки.
  • Более высокая основная версия тоже удовлетворяет рекомендации. Если подходящей версии нет, компилятор может выдать предупреждение и продолжить по правилам RFC 7950. Поэтому завершённое разрешение не доказывает ни выполнения рекомендации, ни совместимости клиента.
  • Перед внедрением нужен протокол разрешения, связывающий запрос, все варианты, проигнорированные признаки, выбранные байты, полный набор модулей, функции, отклонения, предупреждения, испытания клиентов, владельца решения и точку отката. Это предложение Daniel Kade, а не требование IETF.

Слово «минимальная» создаёт лишнее обещание

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

draft-ietf-netmod-yang-semver-28 распределяет обязанности иначе. Редакция опубликована 21 июля 2026 года, остаётся активным Internet-Draft для Standards Track и находится в очереди RFC Editor; это ещё не RFC. Расширение recommended-min-version помещается внутрь инструкции import и принимает только цифровую тройку.

Условию отвечает точная тройка, более высокий patch при тех же major и minor, более высокий minor в пределах того же major или любое более высокое значение major. Модификаторы совместимости и метаданные в сравнении не участвуют. Пример самого проекта не оставляет места для более благоприятного прочтения: при минимуме 3.1.0 подходят 3.1.2 _non_compatible и 4.1.2.

Первая строка прямо сообщает о несовместимом изменении внутри ветки. Вторая переходит на основную версию, рост которой в YANG Semver обозначает несовместимое изменение. Однако числовой фильтр принимает обе.

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

Когда система сборки показывает только зелёный статус «minimum satisfied», организация сама приписывает стандарту гарантию, которой в нём нет.

Версия остаётся важным свидетельством

YANG Semver делает историю модели понятнее. Увеличение major означает несовместимое изменение на основной линии. Увеличение minor обычно означает обратно совместимое развитие в пределах major. Patch без модификатора обозначает редакционную правку. Специальные суффиксы YANG позволяют обслуживать старые ветки, а _non_compatible сохраняется в ветке и не даёт следующей редакционной правке скрыть прежний разрыв.

Кроме того, сочетание имени артефакта и семантической версии должно однозначно определять одну редакцию. Разному содержимому нельзя присваивать одну и ту же пару. Это полезная дисциплина идентичности и происхождения.

Но метка описывает намерение автора модели по заданным правилам, а не результат выполнения всех потребителей. Формально совместимое добавление может сломать клиент, который счёл расширяемое перечисление закрытым. Новый узел может выявить дефект генератора кода. Приложение может зависеть от порядка или описания, которые никогда не были контрактом. Правильная классификация модуля не исправляет скрытые предположения клиента.

Даже хеш отдельного файла не охватывает весь объект. Проект отмечает: смысл подмодуля способен резко измениться при неизменных собственных байтах и редакции, если другой подмодуль изменил используемый grouping или typedef. Хеш фиксирует полученный файл, но не итоговую схему включающего модуля.

Поэтому семантическая версия — структурированное свидетельство заявленной автором линии. Это не криптографическое доказательство содержания, не lock-файл, не испытание соответствия и не разрешение на внедрение.

За одним словом «разрешено» скрываются три состояния

Первое — выполнение числовой рекомендации. Среди видимых вариантов нашёлся тот, что прошёл правила recommended-min-version. Для воспроизводимости нужно сохранить не только победителя, но и весь набор кандидатов: новая публикация в репозитории способна изменить выбор при неизменном импортирующем модуле.

Второе — завершение после возврата к прежним правилам. Если компилятор с поддержкой расширения не находит подходящей версии, проект советует предупредить и продолжить по RFC 7950. В RFC 7950 явный revision-date фиксирует редакцию; без него язык не определяет её тем же точным способом. Компилятор может построить схему после предупреждения, но не превращает этим невыполненную рекомендацию в выполненную.

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

Численно допустимая версия может оказаться непонятной старой библиотеке. Fallback способен выбрать тип старше ожидаемой автором зависимости. Схема может успешно компилироваться, но включённая функция откроет клиенту новую ветвь. Один зелёный индикатор стирает различие между поиском, техническим завершением и проверенным поведением.

Единица совместимости — вся разрешённая схема

RFC 8525 задаёт более широкий контекст. У каждого datastore есть схема, составленная из наборов модулей. В набор входят реализованные модули, модули только для импорта и подмодули; у реализованных модулей указываются поддерживаемые функции и модули отклонений. При изменении содержимого YANG Library меняется content-id.

Две системы с одной версией базового модуля могут предоставить разные поверхности управления. Deviation способен убрать или ограничить ожидаемый узел. Feature может открыть новую ветвь. Изменение типа в импортируемом модуле распространяется на несколько верхних моделей. Номер победившего импорта не описывает весь предмет решения.

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

Пакеты укрепляют согласованность, но их имя и версия не служат универсальным сертификатом. Проект разрешает неполные пакеты для исправлений и логических группировок; часть зависимостей остаётся на среду. Когда пакеты привязаны к схеме datastore, разрешённый результат вместе с дополнительными функциями должен точно совпасть с module-set YANG Library и быть ссылочно полным. Это доказательство композиции, не поведения клиента.

Сравнение схем показывает изменение, а не полный эффект

Проект YANG Schema Comparison предлагает машинно читаемое описание различий между схемами. Это сильнее, чем догадка по номеру: можно увидеть изменённые statements и их классификацию.

Однако сравниватель не запускает сгенерированные bindings контроллера. Он не знает, что скрипт считает leaf обязательным, сборщик отвергает новую identity, а новая notification переводит машину состояний в опасный повтор. Он также не доказывает, что откат одновременно восстановит схему, сгенерированный код, сохранённую конфигурацию и состояние устройств.

Совместимость — это отношение. Нужно назвать разрешённую схему, клиента и его версию, нагрузку и проверенные предположения. Фраза «сравнение совместимо» неполна без исходной схемы, политики классификации и наблюдавшихся потребителей.

Протокол разрешения сохраняет отброшенные признаки

Протокол разрешения начинается с импортирующего модуля: имя, точная редакция, полная семантическая версия, хеш и источник. Запрошенная цифровая тройка сохраняется буквально. Затем перечисляются все видимые инструменту кандидаты с полными строками версий, местоположениями и хешами. Алгоритм вправе не учитывать _non_compatible при сортировке; журнал управления не вправе его забывать.

Для выбранной версии фиксируются точные байты или устойчивый digest, дата редакции, версия и происхождение загрузки. Далее раскрывается весь набор: включённые и исключённые пакеты, реализованные и импортируемые модули, подмодули, функции, отклонения, контекст mount и content-id. Протокол отмечает полноту каждого пакета, локально разрешённые зависимости и правило, решившее каждый конфликт.

Поведение инструмента тоже является доказательством. Записываются компилятор или резолвер и их версия, предупреждения и выбранный путь. Выполнение semver и продолжение по RFC 7950 — разные события. Для сравнения схем сохраняются база, политика и результат без превращения их в сертификат клиента.

Последняя часть относится к потребителям: версии испытанных контроллеров, агентов, генераторов и сборщиков; представительные конфигурации, RPC, notifications и пути состояния; ошибки; владелец остаточного риска; область и срок допуска; точный прежний набор для отката. Успех лабораторного клиента не выдаёт разрешение всем, кто пользуется общим репозиторием.

Протокол не усложняет небольшое расширение импорта. Он не позволяет организации скрыть собственные обязанности за простотой этого расширения.

Источники