版本管理

新功能的开发 和 稳定性的提高 对产品都很重要。但是添加新功能会影响稳定性，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 版本（可能跨了多个版本）定期升级平摊风险（类似小步快跑）。经历过周期长的大项目的同学会有这样的经历，三方库版本长时间不升级，结果出了问题不得不升级到新版本（跨了多个版本）风险巨大。