版本控制和兼容性¶

目标是在不同版本之间实现 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。

ADBC 驱动程序清单 TOML 格式的版本独立于 ADBC 标准和组件。它的版本是一个整数，当前设置为 1。此版本号可以选择包含在清单中作为 manifest_version 键的值。如果存在，它必须设置为 1。如果不存在，则假定为 1。当且仅当驱动程序清单格式发生重大更改时，清单版本号才必须递增。在未来版本高于 1 的清单中，manifest_version 键将是必需的。当前的驱动程序管理器实现必须在读取 manifest_version 高于 1 的清单时出错。