版本号的命名和更新问题

前言
版本号的命名和更新问题，是开发者的责任感和前瞻性的问题。

首先看看某些常见软件的版本号：

Linux Kernel： 0.0.1，1.0.0，2.6.32，3.0.18…，若用 X.Y.Z 表示，则偶数 Y 表示稳定版本，奇数 Y 表示开发版本。
Windows：windows 98，windows 2000，windows xp，windows 7…，最大的特点是杂乱无章，毫无规律。
SSH Client：0.9.8。
OpenStack：2014.1.3，2015.1.1.dev8。
从上可以看出，不同的软件版本号风格各异，随着系统的规模越大，依赖的软件越多，如果这些软件没有遵循一套规范的命名风格，容易造成  Dependency Hell。所以当我们发布版本时，版本号的命名需要遵循某种规则，其中  Semantic Versioning 2.0.0 定义了一套简单的规则及条件来约束版本号的配置和增长。本文根据  Semantic Versionning 2.0.0 和  Semantic Versioning 3.0.0 选择性的整理出版本号命名规则指南。

项目立项时
版本格式：0.0.0

开发阶段时
此时系统尚不稳定，随时可能增减或者修正API。

版本格式：0.次版本号.修订号，版本号递增规则如下：

主版本号：0表示正在开发阶段；
次版本号：增加新的功能时增加；
修订号：只要有改动就增加。
开发完成后，发布API，或进入二方库时
此时系统已经基本稳定，可以对外公布使用，意味着API不再会被随意修改。

版本格式：1.0.0

后续的维护升级时
没有特殊需求不会修改API，尤其是对API进行不兼容的升级，或弃用时要特别谨慎。如果需要弃用API，要提前在一个或几个版本中加入弃用标示或注解，并在文档中，建议用户更换为其他可替换的API，然后在下个主版本号升级时，再真正丢掉弃用的API。

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

主版本号：全盘重构时增加；重大功能或方向改变时增加；大范围不兼容之前的接口时增加；
次版本号：增加新的业务功能时增加；
修订号：增加新的接口时增加；在接口不变的情况下，增加接口的非必填属性时增加；增强和扩展接口功能时增加。
新增接口：如果该新增的接口只是对现有的业务线进行扩展则增加修订号；如果是为了增加新的业务线则增加次版本号。
先行版本号和开发版本号
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。

先行版本号(Pre-release)：意味该版本不稳定，可能存在兼容性问题。
其格式为：X.Y.Z.[a-c][正整数]，如 1.0.0.a1，1.0.0.b99，1.0.0.c1000。
开发版本号：常用于 CI-CD（持续集成和持续交付）。
格式为 X.Y.Z-dev[正整数]，如 1.0.1-dev4。
版本号的排序规则为依次比较主版本号、次版本号和修订号的数值，如 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。

一些修饰的词
alpha：内部版本
beta：测试版
demo：演示版
enhance：增强版
free：自由版
full version：完整版，即正式版
lts：长期维护版本
release：发行版
rc：即将作为正式版发布
standard：标准版
ultimate：旗舰版
upgrade：升级版
特别注意：
版本一经发布，不得修改其内容，任何修改必须在新版本发布！
在接口还没有确定下来的时候，应该先使用开发版本号。
业务功能 > 功能 > 接口
-----------------------------------

软件命名规范

1. 软件版本阶段说明
   
   
   • Base版: 此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。
   • Alpha版: 此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改。
   • Beta版: 该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。
   • RC版: （Release   Candidate）该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几。
   • Release版: 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(Ｒ)。
    
2. 版本命名规范
   
   　　软件版本号由四部分组成，第一个1为主版本号，第二个1为子版本号，第三个1为阶段版本号，第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有5种，分别为：base、alpha、beta、RC、release。例如：1.1.1.051021_beta。
   
   
   

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

    
3. 文件命名规范
   
   　　文件名称由四部分组成：第一部分为项目名称，第二部分为文件的描述，第三部分为当前软件的版本号，第四部分为文件阶段标识加文件后缀，例如：项目外包平台测试报告1.1.1.051021_beta_b.xls，此文件为项目外包平台的测试报告文档，版本号为：1.1.1.051021_beta。
   
   
   
   
   
   
   

   　　如果是同一版本同一阶段的文件修改过两次以上，则在阶段标识后面加以数字标识，每次修改数字加1，项目外包平台测试报告1.1.1.051021_beta_b1.xls
   
   　　当有多人同时提交同一份文件时，可以在阶段标识的后面加入人名或缩写来区别，例如：项目外包平台测试报告1.1.1.051021_beta_b_LiuQi.xls。当此文件再次提交时也可以在人名或人名缩写的后面加入序号来区别，例如：项目外包平台测试报告1.1.1.051021_beta_b_LiuQi2.xls
   
   
4. 版本号的阶段标识
   
   软件的每个版本中包括11个阶段，详细阶段描述如下：
   
   

   阶段名称	阶段标识
   需求控制	a
   设计阶段	b
   编码阶段	c
   单元测试	d
   单元测试修改	e
   集成测试	f
   集成测试修改	g
   系统测试	h
   系统测试修改	i
   验收测试	j
   验收测试修改	k