做 APP - API 的同志，询问下版本号管理的问题

[konakona]

版本号格式： 1.0.1

如果说第一版上线后有些 UI 和界面功能上的改动，使得老接口不可用。发布 1.1.0 版，为了 APP 能支持老接口，服务器上的项目是 copy 一份然后将 git branch checkout 为 1.1.0 。并新增一个 Apache/nginx 虚拟机来接收请求吗？

http://api.aaa.com/v2/[controller]/[action]

[airyland]

为什么不能同个项目 v1 v2 并存。

[ytmsdy]

通过 url 进行区分！
api/v1/news/
api/v2/news/
前台进行区分

[luoyou1014]

建立 module 1.1.0 ， 1.1.0 中的 controller 全部继承 1.0.0 ，这样既保证老接口的访问，又避免新接口去把老接口的功能实现一遍。

[tlday]

可以用 nginx 的负载均衡模块区分 url 转发，不用开新虚拟机 /host 。

[tlday]

@luoyou1014 这样处理的话，未来版本多了，继承层级不会爆炸吗？

[luoyou1014]

@tlday 分三位版本号，最小位变动不加 module ，中间位变动根据接口的是否与老接口重合的情况来决定是够加 module ，最高位变动必加 module 。
我们公司差不多有了七层继承，开启 opcache 性能不是问题，偶尔调试有点麻烦，不过这样的好处就是新版本代码绝对不会影响老版本代码。
如果你们公司业务做的真的非常好，可以定期重构，减少继承层级。

[tlday]

@luoyou1014 好吧，虽然不太能认同你们的做法，但是确实是继承的新姿势 get√，我从来都是开两套…旧的打个 tag/branch ，只做 bug fix ，不再添加新功能。新的继续迭代。因为我觉得版本更新时覆盖更新是大忌。

[Immortal]

app 的网络库底层可以封装点标志信息到 header 头里
然后用 nginx 反向代理到各个后端服务
这样不好的一点是偶尔改了一个接口 整个都要反代过去 除非配置里加判断
不过一般也就维护几个版本 迭代几次 强更一次

[hl]

apigateway

[willakira]

不需要，直接在旧接口的基础上开发新的服务
你这才从 1.0.0 到 1.1.0 就不想兼容旧接口了么…

如果每次版本升级都是一个新的 repo ，一些影响多个版本的旧 bug 的修复和部署会非常非常痛苦。

[yimity]

如果只是继承好处理，但是后端的 model 数据库字段等怎么处理？

[ltye]

也可以在 header 里增加版本号~

[blacklee]

1.0.0 到 1.0.1 绝对需要 API 方面的兼容，这种兼容都做不到，构架师好辞职了。

[tshwangq]

@luoyou1014 你这是真遗传，真继承啊。 不过真实需要继承场景的东西都被版本号给废了

[tshwangq]

我的建议，变动不大的，没有根本冲突的。不需要维护几个 api 。
代码累积改动大，已经有不可兼容或者兼容代价太大，考虑发布不同的版本。
并且做好 api 生命周期，设定好旧版本死亡时间。

[luoyou1014]

@tshwangq 同样的接口，因为新版需要的参数和返回值不同，正好使用继承重写对应的 action ，对应的 model 如果没有改动，直接用，改动一样继承，这样来解决稳定性问题，项目大了之后，稳定性永远是最重要的，挂一次的成本谁都受不了。

复用已有接口很容易产生 bug ，小 bug 改下就可以了，万一是导致大规模出错的问题就很头疼了。

当然最好的还是做自动化测试，这点我们也才刚开始搞，之前因为项目进度压力大，一直没做自动化测试。
@tlday

[realpg]

三位版本号的话，接口发生变动，必然要修改第二位版本号的……
第三位版本号是用来修正小问题的

[mhycy]

一个大版本够了，前端请求没必要区分小版本更新，一个大版本之下再狗屎都要完全兼容

[Observer42]

学习了。。用继承

我们是 1.0 - 1.1 不允许有不兼容，只能添加 api ， 1.x - 2.0 可以不兼容，直接写新 controller 。但 1.x 的 controller 保留直到没有服务调