一句话定位
软件有版本号，软件的设计文档通常没有。EIP-7577 想补的正是这块：给进入 Review 状态之后的 EIP 套用语义化版本 2.0.0——规范章节里破坏性改动升主版本、新增向后兼容内容升次版本、修文字不动语义只升修订号。提案 2023 年 12 月 13 日创建，截至本文撰写时状态是 Stagnant：作者搁置或无人接手，规则本身尚未被流程采纳。
它解决哪种事故
一个 Draft 状态的 EIP 在评审期里平均会被改动多轮：字段改名、编码顺序调整、边界条件收紧。实现者按某个下午抓取的版本写了客户端代码，下一次同步文档时若不逐行 diff，根本不知道 Specification 变了。真实世界发生过协议实现因文档漂移而各客户端理解不一的事故，排查成本远超改一次版本号的成本。EIP-7577 的处方朴素：把改动分级，编号上留下不可伪造的印记，让实现者看号知险。
触发规则的分层
按提案规范，版本方案适用于标准轨（Standards Track）EIP：一旦离开 Draft 状态就必须启用，Draft 期间可以提前启用，有多个团队同时在实现时推荐尽早进入 Review 并开始编号；初始主版本号定为 0。之后主版本对应 Specification 的破坏性变更——改了意味着已按旧号实现的代码必须改；次版本对应向后兼容的新增；修订号覆盖不改变语义的修补。范围切分同样明确：Motivation、Rationale 章节怎么改都不触发版本，只有 Specification 参与运算，版本号只对可执行语义负责。提案还推荐配套一个 CHANGELOG 章节，让工具链能查询规范变更、自动比对客户端与参考测试之间的一致性。
为什么停在 Stagnant
截至撰写时该提案停在 Stagnant——按 EIP 流程，这表示作者不再推进或社区无人接手。复盘原因不需要太多想象：EIP 仓库的元数据字段要为此扩展、各类镜像站与工具链要同步解析版本号，收益却主要落在实现者一个环节。它是一份典型的改善型提案——正确但不紧迫。这类文档在标准库里大量存在：价值在于把问题写清楚了，哪怕流程没有立刻采纳，后来的工具作者随时可以捡起来。
一条实用判断线
对实现者而言，这份提案给出的价值可以压缩成一条操作规则：只要引用的 EIP 主版本号跳动，就把它当作一次代码变更请求来处理；次版本跳动只需补测试；修订号跳动重读一遍措辞即可。反过来说，任何在主版本不变的情况下改了规范语义的做法，都是对这条判断线的破坏。工具链角度同样清晰：客户端仓库的提交信息、测试套件的版本标记、审计报告的适用范围，都可以围绕这串版本号组织起来。语义化版本在软件业是二十年老工艺，搬进标准文档的过程没有任何技术难点，缺的只是把它写进流程的那份文件——而这正是 EIP-7577 想成为的东西。
快速问答
问：EIP 现在完全没有版本概念吗？ 答：Draft 到 Review 到 Last Call 到 Final 的状态流是它当前的粗粒度版本；同一状态内的中间改动没有编号。
问：语义化版本三个数字各管什么？ 答：主版本管破坏性改动，次版本管向后兼容的新增，修订号管不改变语义的修补。
问：Stagnant 的提案还能复活吗？ 答：可以，状态不是死刑；有人提交改动并推进评审就能回到活跃状态。
一个常见误会
常见误读是把版本号理解为草稿质量的评分。恰恰相反：草稿期不编号是刻意的，Draft 阶段的 EIP 人人都能推倒重来，给流沙编号毫无意义；版本号只在评审期与冻结期出现，本质是给文档的不可变性上表——每次主版本跳动，都是在向所有读者承认：之前那版实现，要改代码了。
风险提示：本文仅作技术科普，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。