下载文档原格式
软件版本命名规则
写过很多软件⼩⼯具⽤于⽣产测试，但终究不太明确如何给软件版本命名，先稍作整理如下：
<主版本号>.<次版本号>.<修订版本号>
版本号升级原则：
主版本号：功能模块有⼤的变动。
⽐如增加多个模块或者整体架构发⽣变化。
次版本号：相对主版本号⽽⾔，只是局部的变化。
但该局部的变化造成了程序和以前版本不能兼容，或者对该程序以前的协作关系产⽣了破坏，或者功能上有⼤的改进或增强。
修订版本号：局部的变动，主要是局部函数的功能改进，或者bug的修正，或者功能的扩充。
原则上，⾃第⼀个稳定版本发布后，修订版本号会经常性改动，⽽次版本号则依情况作改动，主版本号改动的频率很低，除⾮有⼤的重构或功能改进。
对于⼩项⽬⽽⾔，甚⾄可以简化为此版本号+修订版本号
如：V0.0.0
下⾯是⼈家发布的软件版本号命名，也可参考。
1. 1.版本命名规范软件版本号有四部分组成，第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有五种，分别为base、alpha、beta 、RC 、 release2. 2.软件版本阶段说明Base：此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。
Alpha ：软件的初级版本，表示该软件在此阶段以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改，是测试版本。
测试人员提交Bug经开发人员修改确认之后，发布到测试网址让测试人员测试，此时可将软件版本标注为alpha版。
Beta ：该版本相对于Alpha 版已经有了很大的进步，消除了严重错误，但还需要经过多次测试来进一步消除，此版本主要的修改对象是软件的UI。
修改的的Bug 经测试人员测试确认后可发布到外网上，此时可将软件版本标注为 beta版。
RC ：该版本已经相当成熟了，基本上不存在导致错误的Bug，与即将发行的正式版本相差无几。
Release：该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式的版本，是最终交付用户使用的一个版本。
该版本有时也称标准版。
3. 3.版本号修改规则（1）主版本号：当功能模块有较大的变动，比如增加模块或是整体架构发生变化。
此版本号由项目决定是否修改。
（2）次版本号：相对于主版本号而言，次版本号的升级对应的只是局部的变动，但该局部的变动造成程序和以前版本不能兼容，或者对该程序以前的协作关系产生了破坏，或者是功能上有大的改进或增强。
此版本号由项目决定是否修改。
（3）修订版本号：一般是Bug 的修复或是一些小的变动或是一些功能的扩充，要经常发布修订版，修复一个严重 Bug 即可发布一个修订版。
此版本号由项目经理决定是否修改。
软件命名规范1.软件版本阶段说明o Base版:此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。
o Alpha版:此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改。
o Beta版:该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。
o RC版:（Release Candidate）该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几。
o Release版:该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。
该版本有时也称为标准版。
一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(Ｒ)。
2.版本命名规范软件版本号由四部分组成，第一个1为主版本号，第二个1为子版本号，第三个1为阶段版本号，第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有5种，分别为：base、alpha、beta、RC、release。
例如：1.1.1.051021_beta。
版本号定修改规则：o主版本号(1)：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。
此版本号由项目决定是否修改。
o子版本号(1)：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。
此版本号由项目决定是否修改。
o阶段版本号(1)：一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。
此版本号由项目经理决定是否修改。
o日期版本号(051021):用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。
此版本号由开发人员决定是否修改。
软件版本号制定规则/BLOG_ARTICLE_3008071.HTM软件版本编号订定是指为软件设定版本号码的方式。
通常，版本号码会以数字订定，但亦有不同的方式。
1 小数这是最常用的一种订定方式。
大部份软件的版号都是用此方法去计算。
一个以此方式来订定编号的例子如：2.4。
通常订定规则为：major.minor(.build)major是最大的版本编号，minor为其次，某些软件可能再细分作build，为更小的版本编号。
通常，正式版的版本编号为“1.0”。
1.0以下的版本（0.x）为测试版，代表仍有一些重大错误（bugs），未正式推出。
在新版本推出时，应更新major、minor或是build（如有）的版号，决定于变更的大小。
当有极大的更新时，会增加major的版号。
而当有大更新，但不至于更新major时，会更新minor的版号。
若更新比较小，例如只是除虫（bug fixing），则会更新build的版号。
以下是一个例子：1.0→1.0.1→1.0.2→1.1→1.1.1→2.0→2.1→2.1.1→3.0→…以上例子中，1.0至1.0.1至1.0.2、1.1至1.1.1、2.1至2.1.1都是小更新；1.0.2至1.1、2.0至2.1都是较大的更新；而1.1.1至2.0和2.1.1至3.0则是重大更新。
有时，小数版本号码后面会有“a”、“b”、“rc”等字样，代表某版本的测试版。
“a”、“b”、“rc”分别代表“alpha”、“beta”和“release candidate”。
例如“2.0a”是2.0的alpha测试版，接着可能发布“2.0b”，是2.0的beta测试版。
跟着，又可能出现“2.0b2”，代表2.0的第2个beta测试版。
当beta测试完结后，又可能推出“2.0rc1”、“2.0rc2”两个版本，分别代表2.0的第一和第二个release candidate测试版。
当一切测试结束后，就会有“2.0”正式版。
软件项目版本号的命名规则及格式版本控制比较普遍的 3 种命名格式:一、GNU 风格的版本号命名格式:主版本号. 子版本号[. 修正版本号[. 编译版本号]]Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Number]]示例: 1.2.1, 2.0, 5.0.0 build-13124二、Windows 风格的版本号命名格式:主版本号. 子版本号[ 修正版本号[. 编译版本号]]Major_Version_Number.Minor_Version_Number[Revision_Number[.Build_Number]]示例: 1.21, 2.0三、.Net Framework 风格的版本号命名格式:主版本号.子版本号[.编译版本号[.修正版本号]]Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Number]]版本号由二至四个部分组成：主版本号、次版本号、内部版本号和修订号。
主版本号和次版本号是必选的；内部版本号和修订号是可选的，但是如果定义了修订号部分，则内部版本号就是必选的。
所有定义的部分都必须是大于或等于0 的整数。
应根据下面的约定使用这些部分：Major ：具有相同名称但不同主版本号的程序集不可互换。
例如，这适用于对产品的大量重写，这些重写使得无法实现向后兼容性。
Minor ：如果两个程序集的名称和主版本号相同，而次版本号不同，这指示显著增强，但照顾到了向后兼容性。
例如，这适用于产品的修正版或完全向后兼容的新版本。
Build ：内部版本号的不同表示对相同源所作的重新编译。
这适合于更改处理器、平台或编译器的情况。
Revision ：名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。
这适用于修复以前发布的程序集中的安全漏洞。
软件版本管理规定（范本）1范围本标准规定了软件版本的控制与管理。
本标准适用于软件版本的控制与管理。
2术语和定义下列定义适用于本标准。
2.1软件指与产品相关的所有软件，可以分为产品软件和演示软件。
2.2产品软件已签订合同，有明确交付日期的产品。
2.3演示软件处于研发阶段，并未正式投入生产的应用。
3软件版本命名规则3.1软件版本命名组成产品的正式软件版本命名由四部分组成。
第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号。
产品的演示版本命名由四部分组成。
第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号。
3.2产品软件版本命名产品软件版本的命名规则如下所示:产品标识ZS_VX.Y.Z_YYYYMMDD版本号和时间之间以下划线分隔。
具体含义见表1。
3.3演示软件版本命名演示软件版本的命名规则如下所示:产品标识YS_VX.Y.Z_YYYYMMDD版本号和时间之间以下划线分隔。
具体含义见表1。
3.4 正式版本号的升级规则软件的正式版本号升级，应该能体现出版本继承性关系，根据软件改动的大小，进行正式版本号升级。
3.4.1软件版本升级规则1)研发阶段主版本X的值为0，上线主版本X升级为1，后续根据系统调整需求大小或者合同的约定修改主版本号，如第一期合同主版本号为1，第二期合同主版本号为2；2)软件的初始正式版本号为V1.0.0；3)软件次版本号根据修改的功能及工作量依次递增。
如增加一项大的功能，则次版本号增加1；4)修订号及时间：在没有增加或减少大功能情况下的改动，使用修订号。
同一天发布的修订版本不超过10个，如2018年3月1日，共对一个软件做了3次修改，软件主版本号及次版本号为1和1，则这一天发布的版本分别为:ZS_V1.1.0_20180301、ZS_V1.1.1_20180301、ZS_V1.1.2_20180301。
3.4.2演示版本升级规则1）演示版本X的值为0，不做升级。
关于软件版本号的问题完全的版本号定义，分三项：：<主版本号>.<次版本号>.<修订版本号>，如 1.0.0。
版本号升级原则：主版本号：功能模块有大的变动，比如增加多个模块或者整体架构发生变化。
次版本号：和主版本相对而言，次版本号的升级对应的只是局部的变动。
但该局部的变动造成了程序和以前版本不能兼容，或者对该程序以前的协作关系产生了破坏，或者是功能上有大的改进或增强。
修订版本号：局部的变动，主要是局部函数的功能改进，或者bug的修正，或者功能的扩充。
*********************************************************** ******************************各种软件的版本号是怎么确定的，怎样的跨越才能算是由bate到正式版？原则上，自第一个稳定版本发布后，修订版本号会经常性改动，而次版本号则依情况作改动，主版本号改动的频率很低，除非有大的重构或功能改进。
对于小项目而言，甚至可以简化为：>.<次版本号>.<修订版本号>。
版本号比较自由，至于Beta版或者是正式版跟版本号之间并没有任何关系，只要达到正式版的要求的话，即使版本号是1.0或者0.1都可能是正式版的。
* Alpha版: 此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改。
* Beta版: 该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。
* RC版: 该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几。
* Release版: 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。
版本控制比较普遍的 3 种命名格式 :一、GNU 风格的版本号命名格式 :主版本号 . 子版本号 [. 修正版本号 [. 编译版本号 ]]Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Num ber]]示例 : 1.2.1, 2.0, 5.0.0 build-13124二、Windows 风格的版本号命名格式 :主版本号 . 子版本号 [ 修正版本号 [. 编译版本号 ]]Major_Version_Number.Minor_Version_Number[Revision_Number[.Build_Numb er]]示例: 1.21, 2.0三、.Net Framework 风格的版本号命名格式:主版本号.子版本号[.编译版本号[.修正版本号]]Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Num ber]]版本号由二至四个部分组成：主版本号、次版本号、内部版本号和修订号。
主版本号和次版本号是必选的；内部版本号和修订号是可选的，但是如果定义了修订号部分，则内部版本号就是必选的。
所有定义的部分都必须是大于或等于0 的整数。
应根据下面的约定使用这些部分：Major ：具有相同名称但不同主版本号的程序集不可互换。
例如，这适用于对产品的大量重写，这些重写使得无法实现向后兼容性。
Minor ：如果两个程序集的名称和主版本号相同，而次版本号不同，这指示显著增强，但照顾到了向后兼容性。
例如，这适用于产品的修正版或完全向后兼容的新版本。
Build ：内部版本号的不同表示对相同源所作的重新编译。
这适合于更改处理器、平台或编译器的情况。
Revision ：名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。
这适用于修复以前发布的程序集中的安全漏洞。
配置版本号规则及取值范围：
配置版本号的规则及取值范围可以根据不同的应用场景和需求来制定。
以下是一个常见的配置版本号规则示例：
版本号格式：X.Y.Z
其中：
•X：主版本号（Major Version）
•Y：次版本号（Minor Version）
•Z：修订版本号（Patch Version）
主版本号（X）：当软件有了不向后兼容的新特性或功能时递增。
这通常涉及到软件架构、功能或接口的重大变更，使得旧版本的应用程序可能无法与新版本兼容。
主版本号的取值范围通常是1-99之间的整数。
次版本号（Y）：当软件有了向后兼容的新特性或功能时递增。
这意味着新版本的软件可能增加了一些新功能，但旧版本的应用程序仍然可以在新版本上正常运行。
次版本号的取值范围通常是1-99之间的整数。
修订版本号（Z）：当软件有了向后兼容的修复或安全补丁时递增。
这通常是为了修复一些小问题或安全漏洞，而不会引入新的功能或变更。
修订版本号的取值范围通常是1-999之间的整数。
版本号命名规则版本命名规范1. 版本命名规范软件版本号由四部分组成：第一个1为主版本号第二个1为子版本号第三个1为阶段版本号第四部分为日期版本号加希腊字母版本号希腊字母版本号共有5种，分别为：base、alpha、beta、RC、release。
例如：1.0.0.081015_release常规：完全的版本号定义，分三项：：<主版本号>.<次版本号>.<修订版本号>，如 1.0.02. 版本号定修改规则主版本号(1)：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。
此版本号由项目决定是否修改。
子版本号(1)：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。
此版本号由项目决定是否修改。
阶段版本号(1)：一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。
此版本号由项目经理决定是否修改。
日期版本号(051021):用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。
此版本号由开发人员决定是否修改。
希腊字母版本号(beta):此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。
此版本号由项目决定是否修改。
3. 文件命名规范文件名称由四部分组成：第一部分为项目名称，第二部分为文件的描述，第三部分为当前软件的版本号，第四部分为文件阶段标识加文件后缀，例如：rongliaoRCS 1.0.0.081015_release.apk，此文件为项目外包平台的测试报告文档，版本号为：1.0.0.081015_release。
