前言

在研发日常工作中，常常会使用到别人的代码包，绝大部分软件也会有版本号控制。

绝大多数情况下，软件的版本号定义遵循semver语义，是X.Y.Z这种格式的版本号，这个标准是github组织起草的，是个事实上的行业标准。

版本号规则

主要规则

X 代表主版本号

也可以称为major号。当做了破坏性的、颠覆性的改动，已无法与低版本兼容时，更新主版本号。每当主版本号递增时，次版本号和修订号必须归零。

一般从0开始，0作为主版本号，意味着此版本为非正式发布的版本，所有功能均处于测试中，会有较为频繁的功能更新与改动。

当主版本号从0升级为1时，意味着此版本作为正式发布的稳定版本。

Y 代表次版本号

也可以称为feature号。当做了向下兼容的功能性更新时，升级次版本号。每当次版本号递增时，修订号必须归零。

Z 代表修订号

也可以成为bugfix号。当做了向下兼容的小问题修正时， 升级修订号。

先行版本

先行版本号的格式一般为 X.Y.Z-<Tag>.N，如 2.13.5-beta.3。

先行版本类型有以下三种：

alpha

预览版，或者叫内部测试版。一般不会外部发布，仅供内部测试人员测试，会有很多bug，一般开发团队自测完毕后发布。

beta

测试版，或者叫公开测试版，是在经历过alpha版本测试后发布的版本，相对bug较少。此版本经过一段时间公开测试后，进入下一阶段。

rc(release candidate)

发布候选版本，是可能成为最终产品的候选版本，如果未出现问题则发布成为正式版本。

版本号升级场景演示

我现在开发一个新的软件并发布非正式版本，起始版本号为0.1.0。此版本号中的所有功能均作为首个发布版本的内容。

一段时间后，我开发了一个新功能，这时候升级feature版本号，发布版本为0.2.0。

经历过一段时间更新后，现在软件版本号来到了0.4.0，有用户在使用时发现了bug。

我现在修复了这个bug，发布版本为0.4.1。

又经历过一段时间的功能新增与bug修复，现在版本号来到了0.10.5

我认为现阶段软件已经可以作为正式版本发布，升级主版本号，发布新版本1.0.0。

在此版本之后，如果不升级主版本号，则所有功能更新与bug修复均需要考虑向下兼容，经历过一段时间的更新后，版本号来到了1.4.10。

此时，开发团队发现，现有的代码架构已无法支撑新的功能，或不希望再向下兼容过旧的版本。

此时发布新的破坏性版本更新，版本号更新为2.0.0，之后以此类推。

先行版本升级场景示意

现在正在版本1.4.10，开发团队已基本完成2.0.0的开发工作。

现在发布先行预览版进行测试，首先发布2.0.0-alpha.0，作为首个先行预览版本发布，以供内部测试人员测试。

在先行预览版版本中，开发团队仍可进行feature与bugfix更新，所有改动均会作为新版本发布时的更新内容。

经历过一段时间测试，现在内部人员测试完毕，版本号来到了2.0.0-alpha.5。

现在发布公开测试版本2.0.0-beta.0，供其他用户使用与测试，使用此版本的用户应当了解此版本可能会存在的问题的现状。

在公开测试版本中，开发团队一般仅进行bugfix更新，不再新增功能。

经历过一段时间测试，参与测试的用户暂时没有发现更多问题，版本号来到了2.0.0-beta.2。

一般经历过公开测试版本后，便可以正式发布了。

但在更严格、更规范的测试流程与发布流程中，还需进行rc发布后选版本的发布流程。这个过程的版本号更新与前两个流程同理，不再赘述。

写在最后

以上版本号控制仅为理想情况的版本号规范方案。

相对来说，github上的大部分开源软件、组件库、函数库、代码框架，会更加遵守上面这套版本号规范，而实际的软件、游戏的版本号可能由更多不同的因素决定。

例如有的软件会以软件发布年份作为主版本号，每年发布一个新版本，主版本之间并没有严格意义上的兼容性区别，不兼容的版本一般厂家会强制用户更新版本。

在线游戏也常常是一年发布一个新的主版本，以游戏运营的版本周期更新次版本号，而热更新和bug修复更新的修订版本号，用户一般不感知。

在线游戏版本的最大特点是，在线游戏一般均会强制升级所有版本号，用户无法使用旧版本使用。

单机游戏则情况更加复杂，有的是版本之间存档互不兼容，有的则相近版本之间互相兼容，但一般旧版本支持升级到新版本，但不支持新版本回到旧版本。