关于版本管理这件事，最近我是真的遇到困难了。我在负责版本管理与发布工作，每一次的版本迭代，我们都会要求客户前、终端程序同步更换，也就是说升级的后台兼容不了旧有的终端页面。今天和开发就这件事讨论了一下，以下是一些心得，共勉。
故事要从，我和开发人员的一次真诚讨论（撕）开始说起……
角色说明：
我 产品经理
小Z 后台开发人员
我：“Hi,小Z同学，请教件事情哈。以后咱们扩展接口的时候，是否可以保留旧的返回数据呢？”
小Z同学：“兼容上一个版本的返回值，不一定能做……”
我：“例如这次你扩展了3.26接口，删掉了几个返回值，所有的终端页面就得全部重新对接了。”
小Z同学：“重新对接很简单的嘛。如果不删掉旧的返回值，数据越来越多，以后交接任务就没人看的懂了。”
我：“你说的也有道理哇，那怎么在数据冗余与兼容性之间做平衡呢？”
小Z同学：“你弄懂之后告诉我哈……”
我：“……”
我的思考：我们手机上使用的app，很长时间不更新，也不影响正常使用。那么这些互联网公司，是采用什么策略呢。
带着这个问题，我请教了大学同学大K。大K在互联网企业负责一款教育类app的开发工作，他应该能解答我的这个问题。
我：“大K大神，有个问题请教。关于版本兼容，……（此处省去若干字）”
大K：“这第一点嘛，后台返回的数据定义为JSON，约定好对于JSON中的属性，只增不减。”
我：“只增不减，那数据不就会越来越多吗？”
大K：“是的，数据越来越多，会带来两个问题，1.耗费网络资源；2.不利于产品维护。”
我：“这就是我的疑问，快给我指条明路。”
大K:“如果为了解决数据越来越多带来的问题，需要对旧数据进行清理，就要进行重大升级，强制用户更新。”
我：“也就是说，产品迭代以兼容旧版本为第一目标；当返回数据越来越多需要清理时，对产品进行重大升级，此时只能强制用户更新。”
大K：“是的”
总结：
- 数据库的设计要有前瞻性，这样在后期做迭代的时候不必伤筋动骨；
- 接口根据版本进行分类，例如/api/1.0/user/register;/api/2.0/user/register；
- 若需要新增参数，加默认值兼容旧版本；
- 涉及到与旧数据关联不大的新数据，新建数据表做一定的冗余即可；（开闭原则：对新增开放；对修改关闭）；
- 监控各版本的API访问情况，对于陈旧的API废弃；
- 对不能兼容的API版本进行报错处理（强制更新）；