API 稳定性¶
API 和 ABI¶
从高层来看，API（应用程序编程接口）是在针对组件进行开发时，两个组件之间的边界。它与 ABI（应用程序二进制接口）密切相关，ABI 是运行时的边界。它定义了其他组件可以与组件交互的可能方式。更具体地说，库的 C 头文件通常构成其 API，编译后的库符号构成其 ABI。API 和 ABI 的区别在于代码的编译：C 头文件中存在某些内容，例如 #defines，可能导致库的 API 更改而 ABI 不变。但这些差异大多是学术性的，并且在实际用途中，API 和 ABI 可以互换使用。
C 函数 API 不兼容的更改示例包括添加新参数、更改函数的返回类型或删除参数。
然而，项目的许多其他部分也可以构成 API。如果守护进程在 D-Bus 上公开自身，则在那里导出的接口构成 API。 同样，如果 C API 通过使用 GIR 在更高级的语言中公开，则 GIR 文件构成另一个 API——如果它发生更改，则任何使用它的更高级代码也必须更改。
其他更不寻常的 API 示例包括配置文件位置和格式以及 GSettings 模式。对这些的任何更改都可能需要使用您的库的代码进行更改。
稳定性¶
API 稳定性是指项目对 API 未来只会以定义的方式更改，或者根本不会更改的某种程度的保证。通常，如果 API 承诺向后兼容（如下定义），则认为 API 是“稳定”的；但 API 也可以承诺不稳定或甚至向前兼容。API 稳定性保证的目的是允许人们从自己的代码中使用您的项目，而不必担心不断更新他们的代码以跟上 API 更改。典型的 API 稳定性保证意味着，针对库的一个版本编译的代码将能够在同一主版本号的该库的所有未来版本上正常运行——或者类似地，针对守护进程运行的代码将能够继续在同一主版本号的该守护进程的所有未来版本上运行。
可以将不同级别的 API 稳定性应用于项目内的组件。例如，库中的核心函数可以是稳定的，因此其 API 在未来保持不变；而较新的、不太核心的函数可以保持不稳定，并允许它们发生剧烈变化，直到找到正确的设计，此时它们可以标记为稳定。
通常考虑的几种类型的稳定性
- 不稳定
API 可能会在未来更改或删除。
- 向后兼容
仅允许允许针对未修改的 API 编译的代码继续在修改后的 API 上运行的更改（例如，不能删除函数）。
- 向前兼容
仅允许允许针对修改后的 API 编译的代码在未修改的 API 上运行的更改（例如，不能添加函数）。
- 完全稳定
不允许对 API 进行任何更改，仅对实现进行更改。
通常，当项目声明 API“稳定”时，它们会承诺向后兼容。很少有项目承诺完全稳定性，因为它会阻止项目几乎所有进一步的开发。
版本控制¶
API 稳定性保证与项目版本控制密切相关；包括包版本控制和 libtool 版本控制。Libtool 版本控制完全是为了跟踪 ABI 稳定性而存在的，并在 Autotools Mythbuster 或 Versioning 上进行了详细说明。
包版本控制 (major.minor.micro) 与 API 稳定性密切相关：通常，当进行向后不兼容的更改时（例如，当函数重命名、参数更改或函数删除时），主版本号会递增。当进行向前不兼容的更改时（例如，添加新的公共 API），次版本号会递增。当进行不修改 API 的代码更改时，微版本号会递增。有关更多信息，请参见 Versioning。
API 版本控制对于 D-Bus API 和 GSettings 模式（如果它们可能更改）与对于 C API 同样重要。有关详细信息，请参阅 D-Bus API 版本控制 文档。
对于 GIR API，它们的稳定性通常遵循 C API 稳定性，因为它们是由 C API 生成的。