杂谈：软件版本号命名规则

为什么要有版本号

版本号看起来只是一个数字串，但它背后承载的是软件交付、兼容性和发布语义的约束。

如果没有统一的版本号规则，软件团队很快就会陷入一种典型的困境：

同一个版本号在不同分支或构建环境中，可能实际对应了不同功能集合；例如开发版、测试版和正式版都被标成了 V1.2.3，但它们各自包含的补丁和功能并不一致。
某个功能在 V1.2.3 上看似“已经完成”，但在另一条分支里又被标成了同一个版本号，结果测试人员和研发人员对同一版本的理解完全不同。
软件看似完成了升级，但由于兼容性约定不清，旧插件、旧配置文件或旧协议接口在新版本中直接失效，结果出现功能不兼容。

这类问题在多模块系统、跨平台发布、持续集成场景下尤其常见。

一个好的版本号，至少应该回答三个问题：

这次变更的影响范围有多大？
新版本和旧版本是否兼容？
当前版本属于开发阶段、测试阶段，还是正式发布阶段？

如果这三个信息不能从版本号中快速读出来，那么版本号就失去了它最本质的价值。

常见的版本号模型

最常见的做法，是把版本号拆成三段：主版本号、次版本号、修订号，也就是常见的 X.Y.Z 形式。

主版本号

主版本号通常用于表示“重大变更”。如果一个版本引入了破坏性接口变化、架构调整，或者明显不兼容旧行为，那么主版本号往往需要递增。

例如从 1.x.x 升级到 2.x.x，通常意味着你不能再假设旧逻辑可以无缝继承。

次版本号

次版本号一般用于新增功能、增强能力、引入可选特性，但这类更新应尽量保持向后兼容。它更像是“功能扩展”，而不是“架构重写”。

如果某个功能在旧版本上可用，但新版本加入了更丰富的能力，那么次版本号就比较合适。

修订号

修订号通常用于修复已知问题、补丁更新和稳定性提升。它的语义通常比较明确：这次版本主要是在“修复问题”，而不是“引入新能力”。

发布后缀

除了核心三段式版本号，很多项目还会加入后缀来说明发布阶段。比如：

alpha：内部测试版本，功能可能不稳定
beta：开放测试版本，问题仍然可能存在
rc：候选发布版本，接近正式发布
release：正式发布版本

补充标识

有些项目还会在版本号里额外加入构建时间、Git Commit ID、定制版标志等信息。这类信息非常适合用于定位问题、追溯构建来源，但它们并不能替代版本号的主语义。

也就是说：

X.Y.Z 用来表达“功能和兼容性变化”
alpha/beta/rc 用来表达“发布成熟度”
构建时间、提交 ID 等用来表达“具体是哪一次构建”

这三类信息各司其职，不能混淆。

常见误区

很多版本号问题，根本不是设计得不好，而是规则本身没有被明确约束。

常见误区包括：

只按时间递增版本号，却没有表达兼容性变化
主版本号、次版本号、修订号使用混乱，语义不清
预发布阶段后缀乱用，导致用户误判版本状态
版本号和实际功能更新脱节，发版说明与版本号不一致

这类问题会让维护者和使用者都难以判断。

落地建议

如果你要设计一套自己的版本号规则，建议遵循下面的原则：

明确版本号三段语义
- 主版本号：是否存在破坏性变化
- 次版本号：是否新增功能
- 修订号：是否只是补丁修复
发布阶段必须可见
- 通过 alpha、beta、rc 等后缀，明确当前处于开发测试还是候选阶段。
版本号要和发布说明一致
- 如果你声明是“兼容性增强”，版本号就不应该看起来像一次破坏性升级。
不要把版本号变成纯数字累加器
- 版本号应该是“信息载体”，而不是“计数器”。
与 Git 结合的发布策略
- 主线分支 main 作为开发主干，所有新功能先在主线分支上合入。
- 当某个版本进入稳定期时，可以从主线分支创建维护分支，例如 V1.1.x、V1.2.x。
- 维护分支在发布后通常只接受补丁修复，不再继续叠加新功能，避免影响已有兼容性。
- 维护分支发布前，可先使用 alpha 进行内部验证；验证通过后再发布 beta 或 release 供测试和用户使用。
- 发布时打上 Git tag，便于追踪版本来源、回溯问题和定位构建产物。

flowchart LR
    A[main 开发主干] --> B[V1.x 维护基线]
    B --> C[V1.1.x 修复线]
    B --> D[V1.2.x 修复线]
    C --> E[alpha -> beta -> release]
    D --> F[alpha -> beta -> release]
    E --> G[tag: v1.1.5]
    F --> H[tag: v1.2.2]
    A --> I[V2.x 重构基线]