版本管理
新功能的开发 和 稳定性的提高 对产品都很重要。但是添加新功能会影响稳定性,Dubbo 使用如下的版本开发模式来保障两者。
2 个版本并行开发
- BugFix 版本:低版本,比如
2.4.x
。是 GA 版本,线上使用的版本,只会 BugFix,升级第三位版本号。 - 新功能版本:高版本,比如
2.5.x
。加新功能的版本,会给对新功能有需求的应用试用。
2.5.x
的新功能基本稳定后,进入 2.5.x
试用阶段。找足够多的应用试用 2.5.x
版本。
在 2.5.x
够稳定后:
2.5.x
成为 GA 版本,只 BugFix,推广使用此版本。如何可行,可以推进应用在期望的时间点内升级到 GA 版本。2.4.x
不再开发,应用碰到 Bug 让直接升级。(这个称为“夕阳条款”)- 从
2.5.x
拉成分支2.6.0
,作为新功能开发版本。
优势
- 保持 GA 版本是稳定的!因为:
- 只会作 BugFix
- 成为 GA 版本前有试用阶段
- 新功能可以高版本中快速响应,并让应用能试用新功能。
- 不会版本过多,导致开发和维护成本剧增
用户要配合的职责
由于开发只会 BugFix GA 版本,所以用户需要积极跟进升级到 GA 版本,以 Fix 发现的问题。
定期升级版本用户带来了不安。这是一个假命题,说明如下:
- GA 经过一个试用阶段保持稳定。
- GA 版本有 Bug 会火速 Fix
- 相对出问题才升级到 GA 版本(可以跨了多个版本)定期升级平摊风险(类似小步快跑)。经历过周期长的大项目的同学会有这样的经历,三方库版本长时间不升级,结果出了问题不得不升级到新版本(跨了多个版本)风险巨大。