随着程序业务量的上升，让整体用户全部版本更新时越来越提心吊胆，担心出问题，所以需要引入灰度发布机制，并且有些业务和现有业务冲突，必须让用户强制更新才能使用新功能，还有一些更新只想提示指定范围的用户，所以现整理一套版本更新方案，以供大家参考。
基础概念：
最新版本号 —— 管理员等程序上线通过审核后，把当前程序的最新版本号手动录入后台管理系统，以做更新校验用。
是否出弹框 —— 在程序首页是否出更新提示的弹框。
是否强制更新 —— 在程序首页出更新提示的弹框，并且此弹框是否能被关闭。
更新范围 —— 根据用户的类型，地域范围和当前版本号等信息判断是否要提示更新。
更新内容 —— 弹框内的更新提示文案。
对应平台 —— 判断这次更新提示适用于哪个平台（防止iOS和Android版本号和更新内容不统一）。
设置/检测版本 —— 在设置界面增加用户直接检测版本的按钮，如果最新版本号大于当前版本号，就出更新弹框，可以选择关闭或去更新。
根据此设计方案
Cms管理系统只需考虑对更新提示信息的录入操作，除了上图的录入内容，还需注意最好每次的录入都保存一条记录，防止更新过程中，对之前的版本记录不清楚，并且更新提示发布时可以设定生效时间，以防录入错误马上生效。
移动端只需请求接口时上传自己的token，当前程序版本号和平台类型，然后接受返回数据，在首页只需根据“是否出弹框”，“是否强制更新”，“更新内容”，“版本号”四个字段进行业务判断处理。在设置/检测更新界面，只需根据“更新内容”，“版本号”两个字段判断是否出更新提示。
服务接口端需要接受移动端的token，当前程序版本号和平台类型，然后和Cms管理系统录入的更新信息作对比，确定返回给移动端怎么样的提示信息。
后记
如果上图的更新提示方案既不想让用户频繁刷新更新接口，又想完全拦截住老版本的冲突业务，还可以在程序所有接口上加版本号的公共参数，如果接口判断是老版本号，已经不支持现有业务，可以在接口公共返回值层面提示用户更新。
