版本发布是软件工程中最日常、也最被低估的动作。大多数团队将其视为一个技术流程：改号、打包、上线。但如果你把时间拉长到十年，就会观察到一种近乎悖论的现象——版本号越来越严谨，发布节奏越来越快，而用户对"新版本"的恐惧与疲惫却与日俱增。传统意义上的"版本"是产品演进的里程碑，而今天，它更像是一种心理暗示：提醒用户世界已变，你又该重新学习了。
我们不妨对比三种主流范式。第一种是传统的顺序版本号，如v1.0、v2.0，它建立在"交付即完成"的瀑布思维上，强调一次性正确，版本之间泾渭分明。第二种是语义化版本（SemVer），它以MAJOR.MINOR.PATCH的规则试图在兼容性与自由度之间建立数学式的精确契约。第三种则是持续发布，如GitHub或Figma的做法，版本号变得不重要，甚至被隐藏，用户只感知到无感的变化。这三种范式并非简单的技术选型，而是三种不同的世界观：传统版本信仰确定性，语义化版本信仰规则，持续发布信仰流动。
我的独立观点是：版本发布从来不是软件的技术属性，而是团队与用户之间的认知契约。传统版本号是"一次性博弈"的保证书，语义化版本是"长期博弈"的法律条文，而持续发布则是"无限博弈"的信任投票。遗憾的是，大多数团队在使用语义化版本时，只复制了它的符号，却未继承它的精神——他们用MAJOR号标记重大重构，却不敢在MINOR中引入破坏性变更；他们宣称遵守SemVer，却在依赖中悄悄改掉行为。这种符号与行为的撕裂，恰恰是版本发布被误解最深的地方。
更进一步，持续发布并不适合所有场景。对于底层库、协议或基础设施，语义化版本的清晰边界仍然是必要的。而面向终端用户的产品，持续发布才是更人道的选择——用户不该被"升级"绑架，也不该因版本号产生焦虑。因此，真正的工程智慧不是追逐某种潮流，而是识别你的产物处于何种信任层级。在版本发布之上，我们真正应该管理的不是数字，而是变更的可见度与不可见度的配比。
最终，版本发布会走向消亡，但这不是因为混乱，而是因为价值流变得足够透明——用户不再需要版本号来判断是否安全，系统会通过自动回滚、灰度分析来保障安全感。到那时，版本号将退化为纯粹的内部审计标签，像仓库里的批次号一样无声无息。而今天，我们所有对版本发布的讨论与纠结，其实都是在为一个更根本的问题做沙盘推演：如何在熵增的世界中，让信任有序地流动。
