产品版本号的定义规则

产品工作难免涉及到给产品定义版本号，事情虽小但是也有讲究，本篇结合网上看到的资料，聊聊版本号应该怎样去定义。

在我们下载或更新软件时，经常会看到一串版本数字，这就是所谓的版本号。

版本号一般由产品经理或项目经理给定义。

那么这些我们经常打交道的版本号是如何去命名的呢？

命名规则

一般我们使用语义化版本（Semantic Versioning）的命名方式，简称 SemVer。

官方网站：semver 版本管理规范

中文译本：https://semver.org/lang/zh-CN/

版本号的格式为 X.Y.Z(又称 Major.Minor.Patch)，递增的规则为：

X：主版本号，重大升级改动，一般 API 的兼容性变化时，包括但不限于新增特性、修改机制、删除功能， 一般不兼容上一个主版本号。

Y：次版本号，新增或修改功能时，必须是向前兼容，不影响软件的整体流程或概念的更新。

Z：修订号，一般做 Bug 修复时。

除去这三个主要的版本描述，还可以在后面加一些特别标记，比如要增加软件的更新总数、或者是特别标注发布日期等等。

例如下面这个版本定义：

54，表示的是当前软件的主要版本

1，表示的是次要版本

30，表示的是主要修复版本

7，就是一个额外的版本说明，可以自定义它的作用

还可以增加例如 beta字样表示是公测版本，例如 2.0.4 beta2 表示第二个beta版本

通用的版本定义可以给用户和合作伙伴带来清楚的认知，知道产品处于什么阶段。

PS：一般来说不用新增修订号。

控制规范

1. X, Y, Z 必须为非负整数，且不得包含前导零，必须按数值递增，如 1.9.0 -> 1.10.0 -> 1.11.0
2. 0.Y.Z 的版本号表明软件处于初始开发阶段，意味着 API 可能不稳定；1.0.0 表明版本已有稳定的 API。
3. 当 API 的兼容性变化时，X 必须递增，Y 和 Z 同时设置为 0；当新增功能(不影响 API 的兼容性)或者 API 被标记为 Deprecated 时，Y 必须递增，同时 Z 设置为 0；当进行 bug fix 时，Z 必须递增。
4. 先行版本号(Pre-release)意味该版本不稳定，可能存在兼容性问题，其格式为：X.Y.Z.a-c，如 1.0.0.a1，1.0.0.b99，1.0.0.c1000。
5. 开发版本号常用于 CI-CD，格式为 X.Y.Z.dev[正整数]，如 1.0.1.dev4。
6. 版本号的排序规则为依次比较主版本号、次版本号和修订号的数值，如 1.0.0 < 1.0.1 < 1.1.1 < 2.0.0；对于先行版本号和开发版本号，有：1.0.0.a100 < 1.0.0，2.1.0.dev3 < 2.1.0；当存在字母时，以 ASCII 的排序来比较，如 1.0.0.a1 < 1.0.0.b1。

注意事项

• 版本号前不要加 v。
• 不要在数字前补 0。错误示例：01.12.03。
• 每一位版本号按照 +1 的速度递增，不要在版本号之间跳跃。
• 主版本号停留在 0 的版本号，即 0.x.x 应当视作还在内部开发阶段的代码。如果代码有公共 API，此时不宜对外公开。
• 1.0.0 的版本号用于界定公共 API 的形成。
• 当次版本号递增时，修订号归零；当主版本号递增时，次版本号、修订号归零。
• 进行新的开发时，版本号从 0.1.0 开始。
• 如果不小心把一个不兼容的改版当成了次版本号发行，应当发行一个新的次版本号来更正这个问题并且恢复向下兼容。注意 不能去修改已发行的版本。

PS：上述来自淘宝FED

版本号的价值

上述都是版本号的一些定义，它在产品工作中到底有何价值？尤其是在非软件的产品之中，是不是版本号就完全没有价值了？

就我在非软件的互联产品经验而言：

1.版本号能协助产品管理迭代

带版本号的迭代排起来非常简洁清晰，产品也能根据版本号大致清楚产品所处的阶段。

2.版本号让项目成员清楚版本的变动意义

用项目成员看到排期中变动是 X，则知道此事必定不小，当看到变动的是 Z，则可以预判大概率是修bug。

3.版本号让项目成员清晰当前版本所处的前后迭代

定义了版本号就不会开发问，前一个迭代是啥？接下来的迭代是啥？哪怕你说了N次也不会在意。

有了版本号，数字上的体现就直接明确了。

总之，定义好版本号后按照规则变动，会瞬间感觉专业和条理了很多！