版本和兼容性

目标是在版本之间保持**ABI 兼容性**。因此，做出了一些选择

• 大多数结构不包含嵌入式字段或函数，而是使用自由函数，这使得添加新函数变得容易。

• 枚举通过typedef/#define定义。

当然，我们永远不能添加/删除/更改结构体成员，并且我们永远不能更改现有函数的签名。

在 ADBC 1.1.0 中，决定这仅适用于“公共”API，而不适用于驱动程序内部 API（AdbcDriver）。在 1.1.0 版本中向此结构添加了新成员。兼容性处理如下

驱动程序入口点，AdbcDriverInitFunc，被赋予一个版本和一个指向函数指针表的指针以进行初始化（AdbcDriver）。表的尺寸将取决于版本；当接受新的 ADBC 版本时，可以扩展新的函数指针表。对于每个版本，驱动程序都知道表的预期大小，并且不得读取/写入超出该大小的字段。如果/当我们添加新的 ADBC 版本时，以下场景是可能的

• 更新的客户端应用程序使用旧的驱动程序库。客户端将传递一个比驱动程序识别的版本更大的version字段，因此驱动程序将返回ADBC_STATUS_NOT_IMPLEMENTED，并且客户端可以决定是中止还是使用旧版本重试。

• 旧的客户端应用程序使用更新的驱动程序库。客户端将传递一个比驱动程序识别的版本更低的version，因此驱动程序可以报错，或者如果它仍然可以实现旧的 API 契约，则初始化对应于旧版本的表的子集。

这种方法不允许我们更改现有函数的签名，但我们可以添加新函数并删除现有函数。

版本控制

ADBC 的版本控制与核心 Arrow 项目分开。API 标准和组件（驱动程序管理器、驱动程序）也分别进行版本控制，但都遵循语义版本控制。

例如：组件可以进行向后兼容的版本发布，例如 1.0.0、1.0.1、1.1.0、1.2.0 等。它们可以发布向后不兼容的版本，例如 2.0.0，但仍然实现 API 标准版本 1.0.0。

类似地，本文档描述了 ADBC API 标准版本 1.1.0。如果/当进行兼容性修订时（例如，定义新的标准选项或 API 函数），下一个版本将是 1.2.0。如果进行了不兼容的更改（例如，更改函数的签名或语义），下一个版本将是 2.0.0。