摘要

  • recommended-min-version 是数值导入提示。YANG 语义版本草案第 28 版规定，比对时忽略 _compatible、_non_compatible、预发布元数据和构建元数据，也允许更高的主版本通过。
  • 因而“解析成功”“满足建议”和“对客户端兼容”是三个不同结论。若找不到合格版本，编译器还可以先发出警告，再按 RFC 7950 的既有规则继续解析。
  • 上线授权应当建立在一份解析收据上：保存请求、全部候选、被忽略的信息、所选文件、完整模块集合、特性、偏差、警告、客户端测试、责任人和回退目标。解析收据是 Daniel Kade 的治理建议，不是 IETF 规范字段。

“最低”这个词替组织做了过多决定

“最低版本”看起来像一道安全门槛。低于它的版本不合格，高于它的版本似乎自然更好。如果数字采用语义版本形式，人们还会补上一个熟悉的假设：主版本上升意味着破坏性变化，所以依赖工具理应阻止无意跨越。

draft-ietf-netmod-yang-semver-28 的设计没有作出这种承诺。该版本发布于 2026 年 7 月 21 日，目前处于 RFC Editor Queue，目标为 Standards Track，但仍是可变更的 Internet-Draft，并非 RFC。它在 YANG 的 import 下定义 recommended-min-version 扩展，参数只有主、次、修订三个整数。

候选比对也只看这三个整数。主次版本相同而修订号更高，可以通过；主版本相同而次版本更高，可以通过；只要主版本更高，也可以通过。兼容性修饰符和各种元数据不参与排序。草案给出的 3.1.0 示例非常坦率：3.1.1 _compatible、3.1.2 _non_compatible、3.3.0-00 和 4.1.2 都符合最低版本条件。

这不是规范内部的逻辑漏洞。草案明确表示，接受更高主版本和 _non_compatible 是有意为之，目的是保持导入解析规则简单。模块版本集合是否一致，应由扩展之外的机制负责，例如 YANG package。换言之，这条规则只决定候选是否进入数值上的可选区间，不决定控制器是否能承受它。

问题由此从语法转向治理。编译器说“条件已满足”时完全正确；变更系统如果把这句话缩短为“兼容性已证明”，就创造了一个没有签发人的保证。

版本标识是证据，但不是裁决

YANG Semver 的价值很实际。主版本上升表示主线出现非向后兼容变化；次版本通常表示同一主线中的向后兼容扩展；没有修饰符的修订号变化表示编辑性改动。YANG 特有的 _compatible 和 _non_compatible 能描述旧分支上的维护，而且 _non_compatible 具有延续性，后续编辑不会让已经发生的破坏性变化从版本名中消失。

草案还要求，制品名称与语义版本的组合必须唯一指向一个修订；不同内容不能复用同一个名称和版本。这为发布历史提供了清晰身份。

但这些信息表达的是模块作者按照规则声明的变化性质，不是对所有消费方运行结果的证明。一个规范上向后兼容的新增枚举值，可能击中把开放集合误当成封闭集合的旧客户端。一个新节点可能暴露代码生成器的缺陷。即使只是文字修订，文件字节变化也可能触发过度僵硬的供应链校验。版本标识正确，并不能自动修复消费方的隐含假设。

单文件哈希同样不是全部。草案特别提醒：某个子模块自身内容与修订都未改变，其含义仍可能因为另一个子模块中的 grouping 或 typedef 变化而发生剧烈变化。哈希能回答“拿到的是哪个文件”，却不能单独回答“最终解释出的整个 schema 是什么”。

所以最稳妥的定位是：语义版本是一条结构化的作者声明；它不是内容摘要、包锁定文件、兼容性测试报告，也不是上线授权。

三种绿色状态不能合并

第一种状态是数值条件满足。解析器在当时可见的候选中，找到了符合 recommended-min-version 规则的版本。要复现这一结果，不能只保存赢家，还必须保存候选集合，因为仓库里后来出现的新版本可能改变选择。

第二种状态是警告后回退完成。草案规定，如果支持该扩展的编译器找不到可行版本，应发出警告，然后按 RFC 7950 的既有方式继续。RFC 7950 允许通过 revision-date 精确指定导入修订；若没有指定，语言层面并未同样固定究竟使用哪一版。最终构建可能生成 schema，但这不能反过来证明最初的 semver 建议已经满足。

第三种状态才是部署接受。完整解析结果需要面对真实的控制器、采集器、代码生成器、配置样本、RPC、通知和状态路径。变更责任人根据测试覆盖面与回退能力决定是否上线。

三个状态可能各自成立或失败。数值合格的版本可能让旧解析库报错；回退得到的版本可能比模块作者依赖的 typedef 更旧；schema 可以顺利编译，却因为新增启用特性而向客户端暴露全新分支。如果流水线只显示一个绿色勾，组织便无法区分“找到了允许的数字”“编译器设法完成了任务”和“运行风险已经验证”。

兼容性的对象是完整解析集合

RFC 8525 的 YANG Library 给出了更合适的观察范围。一个 datastore schema 是若干 module set 的并集。module set 不仅列出实现模块，还列出仅用于导入的模块和子模块；实现模块还关联启用特性和 deviation 模块。YANG Library 内容改变时，content-id 也应改变。

这意味着同一个基础模块版本可以产生不同的实际管理表面。deviation 可能限制或删除客户端预期的节点；feature 可能打开以前不存在的分支；仅导入模块的类型变化可以传播到多个上层模型。兼容性判断若只记录一个获胜版本，就把真正的输入对象截掉了一大半。

YANG Packages 草案进一步把模块集合变成有名称、有版本的层级结构。一个 package 可以包含其他 package、实现模块、仅导入模块和启用特性，也可以排除继承而来的模块或特性。多个 package 发生版本冲突时，解析规则可自动选择较新版本，这对 hotfix 很方便；若要选择更旧版本，则需要明确建立一个细化后的 package。

package 提高了集合管理能力，却不是普遍兼容证书。草案允许不完整 package 用于 hotfix 或逻辑分组，某些依赖仍要由使用环境解析。当 package 与 datastore schema 绑定时，解析出的 package schema 与额外特性必须精确对应 YANG Library 的 module set，并且引用完整。这是对组合一致性的强约束，但它没有运行任何一个具体客户端。

Schema 差异不等于客户端后果

YANG Schema Comparison 草案试图用机器可读方式描述两个 schema 之间的变化。相比只看版本数字，这种比较更能支持严肃审查：它可以指出哪些语句变化，以及变化如何分类。

它依然无法代替消费方测试。比较器不知道某家控制器如何生成类型，不知道脚本把哪个叶节点当作永远存在，也不知道一个新增通知会怎样影响状态机。它更不能证明回退时能同时恢复模块、生成代码、持久化配置与设备状态。

兼容性是一种关系，至少包含 schema 与客户端两端，还要带上负载与假设。同一套 schema 对容错浏览器可能安全，对使用静态绑定的控制器却不安全。“差异检查通过”必须说明与哪个基线相比、采用什么分类规则、针对哪些消费者做过何种实测。

解析收据要保存算法主动丢弃的信息

一份解析收据先记录导入方：模块名称、精确修订、完整语义版本、内容哈希和来源位置；随后原样保存请求中的数值三元组。接着列出解析器当时看见的全部候选，包括完整版本字符串、位置与哈希。排序可以忽略 _non_compatible，治理记录不能忽略。

对最终选中版本，应保存精确字节或稳定摘要、修订日期、完整版本和取得来源。然后展开整个结果：包含与排除的 package、实现模块、仅导入模块、子模块、特性、deviation、挂载上下文，以及 content-id 或离线等价物。收据要说明 package 原先是否完整、哪些依赖在本地补齐、冲突由哪条规则解决。

工具也有版本和行为。必须记录编译器或解析器身份、版本与全部警告，明确它究竟满足了语义版本条件，还是在失败后走 RFC 7950 回退。若做了 schema comparison，还要保存比较基线、策略和结果，而不是把“差异已生成”包装成“客户端已兼容”。

最后才是授权证据：列明测试过的控制器、代理、生成器和采集器版本，代表性配置、RPC、通知与状态路径，已知失败与剩余不确定性，批准人、部署范围、授权期限和回退到的旧集合。实验室里一个客户端通过，不能因为大家共用仓库就默认为所有客户端获得许可。

解析收据没有要求导入扩展承担所有责任。它只是防止责任在层层转述中消失：数值门槛负责搜索，集合机制负责组合，客户端测试负责行为，变更所有者负责上线。

资料来源