软件版本命名规范 (GNU 风格)

GNU 风格的版本号命名格式

Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Number]]
主版本号.子版本号[.修正版本号[.编译版本号]]

示例

• 1.2.1

• 2.0

• 5.0.0.build-160217

约定

• Major 具备相同名称但不一样主版本号的程序集不可互换。例如，这适用于对产品的大量重写，这些重写使得没法实现向后兼容性

• Minor 若是两个程序集的名称和主版本号相同，而次版本号不一样，这指示显著加强，但照顾到了向后兼容性。例如，这适用于产品的修正版或彻底向后兼容的新版本

• Build 内部版本号的不一样表示对相同源所做的从新编译。这适合于更改处理器、平台或编译器的状况

• Revision 名称、主版本号和次版本号都相同但修订号不一样的程序集应是彻底可互换的。这适用于修复之前发布的程序集中的安全漏洞

程序集的只有内部版本号或修订号不一样的后续版本被认为是先前版本的修补程序 (Hotfix) 更新。

版本号管理策略

1. 初始化项目时，版本号能够为 0.1 或 0.1.0，若是你比较高调的话，可使用 1.0 或 1.0.0

2. 当项目进行了局部修改或 bug 修复时，主版本号 和 子版本号 不变，修正版本号 加 1

3. 当项目在原有的基础上增长了部分功能时，主版本号 不变，子版本号 加 1，修正版本号复位为 0

4. 当项目进行了重大修改或局部修正累积较多而致使的项目总体发生变化，主版本号 加 1，子版本号 和 修正版本号 复位为 0

5. 编译版本号通常为编译器在编译过程当中自动生成，只定义其格式，并不进行人为控制

后缀

版本号后面还能够加入如 Alpha, Beta, Gamma, Current, RC (Release Candidate), Release, Stable 等后缀，后缀后面还能够加入一位数字的版本号。经常使用的后缀以下：

α

Alphal，内部测试版

该版本仅仅是一个初步完成品，一般只在软件开发者内部交流，也有不多一部分发布给专业测试人员。通常而言，该版本软件的 bug 较多，普通用户最好不要安装。

β

Beta，外部测试版

该版本相对于 α 版已有了很大的改进，消除了严重的错误，但仍是存在着一些缺陷，须要通过大规模的发布测试来进一步消除。这一版本一般由软件公司免费发布，用户可从相关的站点下载。经过一些专业爱好者的测试，将结果反馈给开发者，开发者们再进行有针对性的修改。该版本也不适合通常用户安装

γ

Gamma

该版本已经至关成熟了，与即将发行的正式版相差无几，若是用户实在等不及了，尽能够装上一试

RC

Release Candidate，发行候选版

该版本和 Beta 版最大的差异在于 Beta 阶段会一直加入新的功能，可是到了 RC 版本，几乎就不会加入新的功能了，而主要着重于除错（该版本已经至关成熟了，基本上不存在致使错误的 bug，与即将发行的正式版相差无几）。

R

Release，最终发行版

该版本意味“最终释放版”，在出了一系列的测试版以后，终归会有一个正式版本，对于用户而言，购买或使用该版本的软件绝对不会错。该版本有时也称为标准版。通常状况下，release 不会以单词形式出如今软件封面上，取而代之的是符号 (r) ，如 windows nt(r) 4.0, ms-dos(r) 6.22 等。

引用

• http://ethanblog.com/tech/webdev/guidance-of-gnu-style-software-version-number.html

• http://www.cnblogs.com/sdjxcolin/archive/2007/07/02/803376.html

• http://licoolxue.iteye.com/blog/602895

• http://blog.csdn.net/cc_china/article/details/7450775