1、Daily Build版本：在每天RD提交代码后，次日早上获取，并携带4位小版本，如：5.4.0.1

2、灰度版本：即小流量发布的版本，对于大用户规模的产品来说，是有必要先发布一个小流量版本给特定批次的用户，以此收集用户反馈、crash率等；灰度期间的版本与上一个正式发布版本的版本号相同（AndroidManifest中，如：5.3.2），目的是防止被各种手机助手抓包并分发，用户规模被恶意扩大；但在客户端About页显示为新版本，如：5.4.0

3、正式版本：即全流量发布的版本，客户端中的所有版本号都将比上一个正式版本大，如：5.4.1

在AndroidManifest.xml中控制各阶段的版本：

<!--版本类型：1：daily build；2：灰度版本；3：正式版本-->
<meta-data android:name="versionType" android:value="2"></meta-data>
 
<!--灰度期间的版本号，在这里控制-->
<meta-data android:name="grayVersion" android:value="5.3.0"></meta-data>
 
<!--小版本，daily build用，在这里控制-->
<meta-data android:name="subVersion" android:value="1"></meta-data>

1、RD正常开发过程中，versionType的value会保持为1，QA的集成打包环境会自动修改subVersion字段（内部四位版本用，和现在的策略保持不变）

2、灰度期间，QA会将versionType的value修改为2，同时修改grayVersion的value，客户端会自动将此字段读出来，作为client_version，带到server端；同时也显示到客户端的About页面；此灰度期间，QA需保证Manifest节点的versionCode和versionName和上一个已发布的版本一致

3、正式发布时候，QA会将versionType的value修改为3，此时，grayVersion和subVersion都会被忽略，客户端会读取Manifest节点的versionCode和versionName（和现在的策略也保持一样）