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版本、使用量較少的老版本、數據庫不兼容、重大功能升級等建議強制用戶升級。