APP版本号命名规范及原则

Posted 2022-12-04 gao_chun

转载请注明gao_chun的Blog：http://blog.csdn.net/gao_chun/article/details/72417127

APP版本号命名规范及原则

为什么需要规范APP命名？

当我们在需求及业务明确后，产品及设计已经做出了对应的文档及UI图，那么进入研发阶段开始编码实现功能，当功能实现的差不多了之后，期间会需要签出不同的包作为展示或测试，不管当前的进度处于什么阶段，签出对应安装包的时候都会对其进行命名并发送给测试人员。一般往往通过命名，就可以大概知道当前签出的包处于哪个版本阶段，Alpha阶段？Beta阶段？RC阶段？测试人员测试时心里也会有个数。

虽然在很多时候定义App的版本命名规则时随便一拍脑袋就定下来了，而且觉得大家在交流沟通的时候都是一串数字而已，但统一规范版本号后，不管是做更新升级，后台版本接口更新，版本检测，沟通交流等都会方便不少，为了在软件产品生命周期中更好的沟通和标记，我们对APP版本号命名做出一定的规范还是很有必要的。

---

版本命名的规范与原则

在android中版本的意义有哪些呢？Android中有 versionCode 和 versionName，他们分别所代表的意思如下：

• verisonCode 是作为一个内部版本号，必须是整型。用来区分版本的新旧，版本号越大，代表距当前越近的发布版本。这个数字不是给用户使用的，是给开发者内部使用的。
  

• versionName 是向用户展示的版本号，必须是字符串，这个版本号就是我们可以用来遵循规范的位置，可以作为版本比较的，判断是否需要提示更新、是否需要强制更新的依据。
  

很多公司对版本命名都有自己的一套规范，例如：

• <APP名称>_<主版本号>.<子版本号>_<SVN最后提交数> 如：YinLiFang_1.0_10242.apk

• <APP名称>_<主版本号>.<子版本号>.<阶段版本号>_<日期版本号加希腊字母版本号>如： YinLiFang_1.0.0.170517_R.apk

• <APP名称>_<主版本号>.<子版本号>_<日期版本号加希腊字母版本号>如： YinLiFang_1.0.170517_beta.apk

还有其他一些会在主版本号前加一个 v 等等，大体上想表达的意思都差不多，为了规范命名，为了方便以后管理，为了描述当前的包处于哪个阶段。这里大致介绍下软件版本号的组成部分，上面也给出了一些示例，一般由四部分组成：<主版本号>.<子版本号>.<阶段版本号>.<日期版本号加希腊字母版本号> 。 如：1.1.2.170517_alpha 。

那么希腊字母版本号是什么意思呢？
希腊字母版本号共有5种，分别是：base、alpha、beta、rc、release。 完全的版本号定义分三项： <主版本号.><子版本号>.<阶段版本号>（即：1.1.0），下面对版本阶段进行下简单的介绍。

---

希腊字母所代表的版本阶段介绍

Alpha版：也叫α版，此版本主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改。

Beta版：此版本相对于α版已经有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。

RC版：此版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几，测试人员基本通过的版本。

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

---

版本号修改规则

以 YinLiFang_1.0.0.170517_beta.apk 为例

主版本号（1）：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。

子版本号（0）：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。

阶段版本号（0）：一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。

日期版本号（170517）：用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。

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


以上便是对APP版本号命名规范及原则的介绍和总结，不论采用哪种规则去定义，目的都是为了能在软件产品生命周期中更好的沟通和标记。