jOOQ 和向后兼容性
适用于 ✅ 开源版 ✅ 专业版 ✅ 企业版
语义化版本控制
jOOQ 对向后兼容性的理解受到 https://semver.org 上的语义化版本控制规则的启发。这些规则采用 [X].[Y].[Z] 的版本控制方案，可以总结如下
- 如果补丁版本包含错误修复、性能改进和 API 无关的新功能，则 [Z] 递增 1。
- 如果次要版本包含向后兼容的、API 相关的新功能，则 [Y] 递增 1，[Z] 重置为零。
- 如果主要版本包含向后不兼容的、API 相关的新功能，则 [X] 递增 1，[Y] 和 [Z] 重置为零。
jOOQ 对向后兼容性的理解
向后兼容性对 jOOQ 很重要。您选择 jOOQ 作为战略 SQL 引擎，您不希望您的 SQL 出现问题。
但是，API 的某些演变元素在其他 API 中会被认为是向后不兼容的，但在 jOOQ 中则不然。正如稍后在关于 jOOQ 的查询 DSL API 的部分中讨论的那样，jOOQ 的大部分 API 实际上是一种内部领域特定语言，主要使用 Java 接口实现。向这些接口添加语言元素意味着以下任何操作
- 向接口添加方法
- 为了方便起见，重载方法
- 更改接口的类型层次结构（包括原始类型或二进制兼容性影响）
很明显，如果不破坏任何实际实现这些接口的客户端代码，就不可能向 API 添加新的语言元素（例如，新的 SQL 函数，新的 SELECT 子句）。因此，应遵守以下规则
- jOOQ 的 DSL 接口不应由客户端代码实现！仅扩展那些明确记录为“可扩展”的扩展点（例如 自定义 QueryParts）。
- 生成的代码实现这些接口并扩展内部类，因此建议每次升级运行时库时都使用匹配的代码生成器版本重新生成。
- 可以从补丁版本预期二进制兼容性，但不能从次要版本预期二进制兼容性，因为在内部 DSL 中维护二进制兼容性是不切实际的。
- 可以从补丁版本和次要版本预期源代码兼容性，例外情况是原始类型兼容性（请参阅 #11879）以及 API 设计明显不足的罕见情况。
- 可以从补丁版本和次要版本预期行为兼容性。
- 任何 jOOQ SPI
XYZ（旨在实现）都附带DefaultXYZ或AbstractXYZ，可以安全地用作默认实现。
jOOQ-codegen 和 jOOQ-meta
虽然花费了合理的精力来根据语义化版本控制规则维护这两个模块，但次要版本很可能会引入向后不兼容的更改。这将在相应的发行说明中宣布，并且应该是例外情况。
反馈
您对此页面有任何反馈吗？ 我们很乐意听到！