【DevOps 工具链】软件版本号命名规范 - 3种规则(读这一篇就够了)

2023-12-25 23:46:27

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,测试及产品确认之后直接发布该版本。

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

文章来源:https://blog.csdn.net/u014597198/article/details/135200351
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。