并且将下面规则的作为补充：

以一个完整的版本号为例：1.3.6-beta-11

其中，"1.3.6"是标准版本号；"beta"是先行版本号，是可选的；11是编译信息，也是可选的。

1、对于业务系统，以关键的业务标识，来作为“先行版本号”。

比如：1.3.6-Sprint1075，1.3.6-UserManage，这个Sprint1075是此次开发功能的代号，是研发团队相关人员都熟悉易懂的记号，如果没有这种记号，则可以用简单的单词来描述，比如此处的UserManage。

2、对于非业务系统，比如公共组件，对于它们的正式版、非正式版，可以添加常见先行版本号，可选的标识为： 

Alpha: 内部版本

Beta: 测试版

RC(Release Candidate): 即将作为正式版发布

Stable: 稳定版

Final: 最终版

比如：

1.3.6-Alpha（内测版）

1.3.6-Beta（测试版）

1.3.6-RC（候选发布版）

1.3.6（正式版）

1.3.9-Stable（正式版，已非常稳定）

1.3.10-Final（正式版，1.3的最终版、不再更新）

3、对于“编译信息”，规定要加上构建时间（精确到分钟），同时建议加上 构建次数 和 构建原因/明细，例如：

1.3.6-Sprint1075+3.bugfix5106.20170806144700，

根据规则可知，这是“1.3.6-Sprint1075”版本的第3次构建，构建原因是bugfix5106，构建时间是2017-08-06 14:47:00。