遇到的情况
本文针对移动互联网客户端需要兼容旧版的情况，强制升级同一版本的app不在讨论之列。 在开心网的《开心宝宝》项目中，我们的版本遵循下面规范。1.0.1 大功能.小更新.bug修正我们的版本列表如下：1.0、1.1、1.2、1.3、1.42.0、2.1、2.2、2.33.0、3.1…5.0这样一个版本结构，所有版本都可以用，跨度最大时，1.0用户要跟5.0用户并存。然而，以/api/user/info接口举例，经过这么多版本的迭代，版本1.0跟3.0的返回数据可能已经完全不同了。对与这样一个系统，如何设计一个完备的版本兼容非常重要。
理解其中的困难
移动互联网，有别于传统的web开发。其快速迭代、版本升级与传统的web开发相比，有如下困难：
- 用户获取成本高
- 客户端升级成本高，部分用户拒绝升级
- 多个版本服务器端代码量大，急剧拉高维护成本
架构的目的及要求
- 简化版本管理流程,易配置管理
- 缩小服务器端的php代码规模
- 尽量不要引入新的要素
微信群里的讨论
请求形式
1.版本号放在域名， url中 ，参数还是http头里面。响应中是否也带版本信息，放到头里还是内容里面。
2.版本号用域名是比较不被认同的方案，主要原因是域名管理往往跨部门等因素的影响。
3.http头是我个人最赞同的一种方式，可以保持url的整洁。
url参数中携带版本号的方式也很好，但是要注意不要跟业务逻辑的参数名重复。
两种常见的方式
git/svn的tag管理方式
优点，随时切换分支成本低，尤其在git管理代码时。
缺点，如果多个版本需要修改时，代码合并工作量大。
trunk里根据版本做判断
优点，代码的总体规模小（只有一份代码）
缺点，在需要判断版本的地方会有大量的分支语句
我总结的解决方案
最后的解决方案充分利用了php的autoload加载机制和命名空间。
- 假设base是所有业务的基础，是第一个版本，也是生命周期最长的版本。
- v10对版本1..提供服务，最大限度消除业务点上的版本逻辑判断，但是不绝对拒绝。
- v20/v30基于v10版本开发
-
v40版本基于v30版本开发
通过图1可以看出, 此版本管理架构类似于编程语言里的继承关系。
版本管理架构示意图
举例说明
v10 提供a,b,c三个接口
v20 提供a1,b,c三个接口 a1是a的修改
v30 提供a,b1,c三个接口 b1是b的修改
用下面三段代码来具体描述
配置版本： 访问版本 -> 代码版本v10 -> base v11 -> basev20 -> v10 v30 -> v10
基础目录 base 存放大部分公共代码 版本目录 v10/v20 都是版本目录，里面存放此版本与 基础版本不同的逻辑 版本区别以文件为最小粒度，以上面三段代码可以看出。
用户要访问/api/user/info?ver=3.0.1,此时，类的加载顺序依次为:
1.在v30下尝试加载Config.php失败
2.在v10下尝试加载Config.php失败
3.在Base下尝试加载Config.php成功
4.执行相关逻辑
这是限制只能继承一层的原因是尽可能的降低系统的复杂度。这种方式管理代码已经在几个项目中得到一些 验证。系统代码的复杂度可以很大程度上降低，尤其是多个版本迭代、又不能强制升级的系统中。另外需要 注意的就是 :
使用这个方式处理加载时，在经过几个版本的沉淀后，应该将通用部分渐渐沉淀到BASE版本中
发布系统最好带有删除文件功能，否则被部分沉淀后，高版本会依旧使用高版本的代码。
推荐文章
- Bugtags，产品经理的瑞士军刀
http://www.jianshu.com/p/4e9a01fbcf59 - 如何符号化 iOS 的崩溃日志
http://blog.csdn.net/diyagoanyhacker/article/details/41247411 - Android 者开发如何选择测试机列表
http://kvh.io/2015/11/28/android-test-device/
欢迎关注我的订阅号
