软件版本的命名规则

最近在完善实验室项目的软件设计，涉及功能的完善和 Bug 的修复，为了方便管理，更新软件版本号是不错的方法，故总结了下软件版本的命名规范。

软件版本号一般由四部分组成，格式如：主版本号.子版本号.修订版本号.日期版本号+希腊字母版本号。

举个例子：1.2.3.20230128_beta

说明：

• 第一位(1): 主版本号。当功能模块有较大的变动，API 的兼容性发生变化时，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改，且只能递增。

• 第二位(2): 子版本号。当功能有一定的增加或变化，但是不影响 API 的兼容性，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改，且只能递增。

• 第三位(3): 修订版本号。一般是 Bug 修复或是一些小的变动，不影响 API 的兼容性，要经常发布修订版，时间间隔不限，修复一个严重的 Bug 即可发布一个修订版。此版本号由项目经理决定是否修改，且只能递增。

• 日期版本号(20230128): 用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。

• 希腊字母版本号(beta): 也叫里程碑版本号，此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。

希腊字母版本号共有5种，分别为：Base、Alpha、Beta、RC、Release。

• Base 版: 此版本表示该软件仅仅是一个基础框架，通常包括主要功能和结构，但是都没有做完整的实现，只是作为程序设计的一个基础架构。

• Alpha 版: 此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般不向外部发布，是内部测试版，该版本软件的 Bug 较多，需要继续修改。

• Beta 版: 该版本相对于 Alpha 版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，是公开测试版，需要经过多次测试来进一步消除，这个阶段的版本会一直加入新的功能。

• RC 版: (Release Candidate)最终测试版本，该版本已经相当成熟了，基本上不存在导致错误的 BUG，与即将发行的正式版相差无几。

• Release 版: 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release 不会以单词形式出现在软件封面上，取而代之的是符号(Ｒ)。

版本号的详细规则如下：

• 主版本号，子版本号，修订版本号必须为非负整数，且不得包含前导零，必须按数值递增，如 1.9.0 -> 1.10.0 -> 1.11.0

• 主版本号为 0 表明软件处于初始开发阶段，意味着 API 可能不稳定；1.0.0 表明版本已有稳定的 API。

• 当 API 的兼容性变化时，主版本号必须递增，子版本号和修订版本号同时设置为 0；当新增功能(不影响 API 的兼容性)或者 API 被标记为 Deprecated 时，子版本号必须递增，同时修订版本号设置为 0；当进行 Bug 修复时，修订版本号必须递增。

• 先行版本号(Pre-release)意味该版本不稳定，可能存在兼容性问题，其格式为: 主版本号.子版本号.修订版本号.[a-c][正整数]，如 1.0.0.a1，1.0.0.b99，1.0.0.c1000。

• 开发版本号常用于 CI-CD，格式为: 主版本号.子版本号.修订版本号.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。

注意：版本一经发布，不得修改其内容，任何修改必须在新版本发布！