作为移动端产品经理，经常会做APP版本迭代规划，所以不可避免的需要给APP版本确定版号的工作，大多数情况下可能都是拍脑袋确定的版本号。
有些公司可能会有专门的项目经理负责版本管理和版本号的命名，但是绝大多数小公司可能都是产品经理来做这项工作。
在网上搜集了一些资料，才发现APP版本号的命名是有很多规范和原则的，本文就将这些规范和原则分享给各位。
一、为什么要规范APP版本号的命名?
首先需要说明的是哪些人员需要用到APP版本号，第一是产品经理，第二是开发人员，第三是项目经理，第四是用户。
对于产品经理，APP版本迭代基本都是有产品经理发起的，因此很多情况下都是产品经理在进行需求管理和版本规划的时候就大体上划分了版本号，版本号对于产品经理来说可以更好更清晰地筛选和确定每个版本的需求。
对于开发人员，版本号是直接和代码相关的，很多时候不同版本交叉开发，同一时间可能在开发不同版本，为了保障代码的规范和清晰，避免不同版本出现交叉混乱，版本号是极其重要的一环。
对于项目经理来说，版本号是需求管理中唯一标识符，需要根据版本号去管理和分配下发工作，同时也为了在软件产品生命周期中更好的沟通和标记。
对于用户来说，尽管版本号对于用户来说只是一串数字，但是版本号给用户的感知是不断更新的数字，可以通过版本号来判断自己的APP是不是最新的。
二、APP版本号的组成与规范
目前很多情况下，版本号可能只遵循了两个原则和规范，即版本号是唯一的，且是一串数字这个基本原则。
在介绍APP版本号的命名规范和原则之前，我们首先需要了解一些APP版本号的组成是怎样的。
软件版本号有四部分组成：<主版本号.><子版本号>.<阶段版本号>.<日期版本号加希腊字母版本号>
希腊字母版本号共有5种：base、alpha、beta、RC、Release。 例如：2.1.0.181209_Release。
下面对希腊字母版号进行简述：
- Alpha版：也叫α版(开发环境)，此版本主要是以实现软件功能为主，通常只在软件开发者内部交流;
- Beta版：此版本相对于α版已经有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI;
- RC版：此版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几，测试人员基本通过的版本;
- Release版：此版本意味着“最终版本”、“上线版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(R)。
而对于绝大多数APP来说，一般采用的基本都是GNU风格的版本号管理策略，APP完全版本号的组成包括三组数字“<主版本号.><子版本号>.<阶段版本号>”，也即X.Y.Z，其中X、Y、Z都为正整数。
三、APP版本号的命名修改规则
1. 主版本号
- 当APP的多个主要模块有较大的变动，一般情况下，比方说APP新增一个TAB，整个产品结构都改变了;或者新增了新的功能或业务，比方说微信上线钱包，抖音上线直播;
- 主版本号起始值为0或者1，具体需要由产品经理来决定是否需要修改主版本号(PS：大多数可能需要老板拍板)。
2. 子版本号
- 子版本号初始值为0;
- 当APP的较少主要模块发生较大的变动或新增模块(涉及主逻辑变更的)、较多个分支模块发生较大的变动或新增，相对于主版本号而言仅是局部的变动，比方说某个功能上的UI重构，某个页面的优化等，其中较少模块和较多模块需要去定义，一般我们认为较少为小于3个，较多认为是超过3个;
- 子版本号的最大值需要确定，不同的公司可能有最大的值，比方说最大为9，如果超过9，则需要主版本号进1，也有些公司可能不存在最大值，只会在主版本号+1的情况下才会将子版本号归0;这里没有确定的原则和规范，可以由产品经理自己定规则。
3. 阶段版本号
- 阶段版本号初始值为0;
- 什么时候修改阶段版本号，一般是Bug修复、较少个分支模块的变动，比方说视觉、样式、交互、文案等修改的情况;
- 一般情况下，如果只是修复bug，则阶段版本号+1即可;如果既涉及到bug修复，又涉及到较少分支模块的修改，则阶段版号+2;如果超过3个分支模块的修改，则建议直接子版本号+1。
总结
尽管说版本号只是一串数字，但是对于产品经理、开发人员以及用户来说，都是有意义的一串数字。既能规范版本的生命周期，也能方便内部人员的沟通和工作。
拍脑袋去命名版本号是一个不严谨和规范的，而产品经理是需要去追求完美的，希望以上的APP版本的命名规范能够给大家一些参考。
