1、简述

有各种各样的软件版本号命名规则，盘点下常见的规则，从而制定新项目的软件版本号命名规范。

2、常见软件的版本号命名规则

Android：

Android 2.3.1, Android2.3.3, Android2.3.5……，按照主、次、维护的方式构建版本

Windows：

windows 98，windows 2000，windows xp，windows 7…，最大的特点是杂乱无章，毫无规律。

Linux Kernel：

0.0.1，1.0.0，2.6.32，3.0.18…，若用 X.Y.Z 表示，则偶数 Y 表示稳定版本，奇数 Y 表示开发版本。

华为：

V800R007C00SPC100、V100R001C01B031…，按照VRC的版本命名规则模式

3、版本号命名规范整理

3.1、XYZ/MMP

3.1.1、规则

最常见的就是XYZ规则(又称 Major.Minor.Patch)，<主版本号>.<次版本号>.<修订版本号>，如 1.0.0。

• 主版本号

功能模块有大的变动，比如增加多个模块或者整体架构发生变化。
当 API 的兼容性变化时，X 需递增。

• 次版本号

和主版本相对而言，次版本号的升级对应的只是局部的变动。但该局部的变动造成了程序和以前版本不能兼容，或者对该程序以前的协作关系产生了破坏，或者是功能上有大的改进或增强。
当增加功能时(不影响 API 的兼容性)，Y 需递增。

• 修订版本号

局部的变动，主要是局部函数的功能改进，或者bug的修正，或者功能的扩充。
当做 Bug 修复时(不影响 API 的兼容性)，Z 需递增。

3.1.2、确定

原则上，自第一个稳定版本发布后，修订版本号会经常性改动，而次版本号则依情况作改动，主版本号改动的频率很低，除非有大的重构或功能改进。对于小项目而言，甚至可以简化为：>.<次版本号>.<修订版本号>。

版本号比较自由，至于Beta版或者是正式版跟版本号之间并没有任何关系，只要达到正式版的要求的话，即使版本号是1.0或者0.1都可能是正式版的。

• Alpha版（内部版本）:
  此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改；
• Beta版（测试版）:
  该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI；
• RC版（软件正式发布的候选版本）:
  该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几；
• Release版（发行版）:
  该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号®；

其他：

• demo：演示版
• enhance：增强版
• free：自由版
• full version：完整版，即正式版
• lts：长期维护版本
• standard：标准版
• ultimate：旗舰版
• upgrade：升级版
  

3.1.3、举例

软件版本号由四部分组成，第一个1为主版本号，第二个1为子版本号，第三个1为阶段版本号，第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有5种，分别为：base、alpha、beta、RC、release。例如：1.1.1.051021_beta。

• u 主版本号（1）：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改；
• u 子版本号（1）：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改；
• u 阶段版本号（1）：一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改；
• u 日期版本号（051021）:用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改；
• u 希腊字母版本号（beta）:此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。

3.1.4、详细规则

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。

注意：版本一经发布，不得修改其内容，任何修改必须在新版本发布！

3.2、XYZD/MMPD

在XYZ/MMP规则上增加了日期。
用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改

3.3、VRC

3.3.1、规则

在集成产品开发中，推荐VRC的版本命名规则模式，此模式为华为的版本号规则
即：

商标+[子商标]+型号+中(英)文名称+VxxxRxxx[LLL]CxxBxxy[SPxx]

1）[ ]表示可选。

2）“V”、“R”、“C”、“B”、"SP"为分隔符；V后面三位数字；R后面三位数字；LLL可选；C后面两位数字；B后面三位数字；SP后面两位数字，只在热补丁时使用。

3）商标、子商标、型号、中(英)文名称根据产品命名相关规范、指导及规则制定。

3.3.2、对"Vxxx"的说明

“Vxxx”(version)代表某一产品或其系列产品，根据市场定位或开发平台的不同，一个产品分为若干个V 级版本。每个V级版本根据市场竞争需要、技术、功能特性与成本因素等，有一个总体开发规划，按计划开发若干个R(Release)级版本。V 版本可以包含若干个Release版本。

如果满足下列任何一种情况，则必须产生新的Version 版本，即产品的大版本：

• 产品市场定位发生变化，引起产品特性的重大变化；
• 产品平台发生变化，与原有平台不能兼容。

V版本以三位数字表示，数字间不准许有任何其它字母、符号出现，从100开始，不同平台或技术的同类产品尽量采用大数标示，即V后面第一位，如V100、V800。

3.3.3、对"Rxxx"的说明

“Rxxx”(Release) 版本表示产品特性版本，可以包含若干个特性，形成一个具体的系列产品，一个Release 版本纳入什么特性，需要综合考虑市场竞争、技术与成本方面的因素，系列产品也可有自己的特性版本，系列产品可以在特性版本号上用特别的字母或数字表示。产品路标规划确定了该产品所有的大版本(Version)，以及每个大版本(Version)包含的特性版本(Release)、系列产品的发布时间和所包含的特性。特性版本需要按照产品开发流程所规定的各个评审决策点进行评审。

如果满足下列情况，则必须产生新的Release 版本：

• 产品市场定位和产品平台没有发生变化，但是，衍生新的系列产品；
• 综合考虑市场竞争、技术与成本方面的因素，产品特性发生变化，有计划地向市场发布的版本。

R版本以三位数字表示，数字间不准许有任何其它字母、符号出现，从001开始，在同一个V下面以1为单位连续递增，例如：R001、R002。

3.3.4、对"LLL"的说明

"LLL"为海外版本标识符，以三个字母表示，可选。对于国内版本，此项可以省略。具体的对应关系请见附表1( 海外版本标识符和相应的语言(国家)对照表)；如果某个版本可以用于某一个地区，可以在附录中选择本地区的主要国家的标识符作为版本的海外标识。

3.3.5、对"Cxx"的说明

“Cxx”(Customer)表示计划提供给客户的版本，以两位数字表示，数字间不准许有任何其它字母，从01开始，以1为单位连续递增。实现该C版本特性集内特性的各个B版本前应标识出Cxx。Cxx与某些Bxx对应，同一Bxx为Cxx版本时，Cxx不以Bxxy的y位及 SPxx而变化，即同一个Cxx可能对应一个Bxxy或同一Build的多个改错版本或热补丁版本。

3.3.6、对"Bxxy"的说明

“Bxxy”(Build)表示开发与IBT过程中的Build版本。B后面的三位中的前两位xx表示规划的Build划，最后一位y表示每一个Build的过程改错版本，包含了网上问题修改版本和转测试回归版本。其中，

• xx从01开始，以1为单位连续递增；RXX变化时，Bxxy版本复位到B010。
• y从0开始，以1为单位连续递增。Bxx变化时，y复位到0开始。

3.3.7、对"SPxx"的说明

SP是为了解决问题，对网上运行版本的热补丁版本，以两位数字表示，数字之间不允许有任何其它符号，如空格、“.”、"-"等。从01开始，以1为单位连续递增。如果版本不是补丁，SPxx要省略。 例如：SP01、SP02。 SP为某一发布版本的补丁版本，只有对于已经发布的版本需要做补丁版本时才会有此项。做SP时，前面的所有版本序号不变。

3.3.8、举例

1. V100R001B010    表示V100R001的第1个Build的首个转测试版本，不发给客户。
2. V100R001B011    表示V100R001的第1个Build的第1个转测试改错版本。
3. V100R001C01B023    表示V100R001的第2个Build为第1个客户版本，一般用于试验局或ESS局。实际交付件为第2个Build的第3个改错版本。
4. V100R001C01B023SP01    表示对V100R001C01B023的第一个热补丁版本。
5. V100R001B030    表示V100R001的第3个Build的首个转测试版本，不发给客户。
6. V100R001C02B053    表示V100R001的第5个Build为第2个客户版本，可用于试验局、ESS局、或ESP局。实际交付件为第5个Build的第3个改错版本。

4、版本发布周期

• 非紧急情况：按照一般发包管理制度执行
• 紧急情况：如果Bug比较紧急可跳过一般流程，由开发人员尽快修复Bug，测试及产品确认之后直接发布该版本。

建议尊重规则，不留钻空子的口，减少紧急情况的发生。