1、实现目标
发布第N版APP，不影响N版本之前APP的正常使用，不强制用户升级APP版本，兼容多个版本的APP的正常使用。
2、解决思路
服务端维护不同版本APP的api（例如版本参数 v1、v2、v3…），根据手机端传递的URL及版本信息，动态调用对应的api。
3、常见的方案
3.1 常见的URL请求传递版本信息的4中方式
url+版本参数： www.xxx.com/api.xxx?version=v1
www.xxx.com/sys/user/getUserByName?version=v1.0
www.xxx.com/sys/user/getUserByName?version=v2.0
url post： header中添加版本参数（类似token使用）
url路径： www.xxx.com/v1.api.xxx。
www.xxx.com/v1.0/sys/user/getUserByName
www.xxx.com/v2.0/sys/user/getUserByName
二级域名： www.v1.xxx.com/api.xxx
www.v1.0.xxx.com/sys/user/getUserByName
www.v2.0xxx.com/sys/user/getUserByName
3.2 服务器APP代码版本管理
每个APP版本对应一个project，发布时独立部署不同版本的app。可以使用SVN分支功能管理不同版本的project。
降低耦合性，杜绝版本之间的依赖，易于维护。版本独立部署，减少单个节点的负载压力。但是会出现大量重复代码。
同一个project兼容不同APP版本的api。根据请求的版本信息的调用不同的api（常见的路由、请求转发方式）。
减少重复代码的重复，但是不恰当的维护，容易造成代码的臃肿，增加版本之间依赖、bug，降低代码的可维护性，不支持每个版本独立部署。
4 个人推荐
二级域名 + 每个APP版本对应一个project。需求在变化，同时APP版本也在变化，同一个API会经过多人修改，原先精简的API随着时间的流逝变得臃肿，API之间过度依赖，修改某处代码，导致其它未知的错误，代码变得难以维护。因此隔离各个版本的APP代码是非常有用的。
4.1APP端如何动态调用服务器的API
每次APP启动时调用服务器版本api，获取url及版本信息。客户端根据系统默认的版本号version获取对应的URL。例如传递version为v2.0,则返回www.v2.0.xxx.com
[
{
"name": "APP V1.0版本",
"version": "v1.0",
"url": "www.v1.0.xxx.com"
},
{
"name": "APP V1.0版本",
"version": "v2.0",
"url": "www.v2.0.xxx.com"
}
]
5、app版本的数量
维护的app版本过多，增加维护成本。对于一些过时的app版本、使用量较少的老版本、数据库不兼容、重大功能升级等建议强制用户升级。