版本控制

本页讨论了我们的版本控制方式，并提供了关于我们稳定版本的信息。

版本控制策略

我们通常遵循 语义化版本控制（semantic versioning）。基本理念如下：

• “主”版本号（最左侧）：向后不兼容，版本之间的 API 不保证兼容性。
• “次”版本号（中间数字）：您可以从较小的数字升级到较大的数字，但向后降级可能会导致不兼容。
• “错误修复”版本（“补丁”或最右侧）：可互换。数字越大，修复的问题通常越多，但编程接口完全兼容，您应该可以直接替换新的 jar 包并正常运行。

请注意，这是根据编程 API 定义的，而非根据功能定义。如果在“错误修复”版本中引入了一种全新的、很棒的处理方式，且没有增加或更改公共 API，这是有可能的。

目前有一个例外：由于我们仍处于 0.x 主版本阶段，我们将 API 视为测试版，并将“主”版本和“次”版本合并对待。因此，在主版本号为 0 的阶段，次版本号的增加可能导致向后不兼容。这些变动会通过邮件列表进行通知。

对于外部部署，我们建议使用稳定版本标签。当我们在生产环境中部署并稳定运行一段时间且无故障后，该版本才会被视为稳定版本。

标签策略

代码库的标签等同于发布候选版本。每当我们希望将代码带入发布流程（包括一些质量保证周期和部署）时，我们都会为代码打上标签。因此，不能简单地认为一个标签就是稳定版本，它只是代码在经历生产环境质量保证周期和部署过程中的一个固化点。标签一旦创建就不会改变，但我们通常会经历多次标签迭代，才会最终获得一个在生产环境中可用的稳定版本。因此，如果您不了解某个标签包含的内容，建议遵循 发布（Release） 页面上列出的稳定版本。