本文档翻译自：https://docs.conan.io/en/latest/creating_packages/define_abi_compatibility.html#library-types-shared-static-header-only

    让我们看一些与常见场景相对应的示例:

    • my_lib/1.0 是与静态库my_other_lib/2.0 包链接的共享库。当新的my_other_lib/2.1 版本发布时: 我是否需要为my_lib/1.0 创建一个新的二进制文件以与之链接？是的，总是这样，因为实现嵌入在my_lib/1.0 共享库中。如果我们总是想要重建我们的库，即使通道改变 (我们假设通道改变可能意味着源代码改变):
      1. def package_id(self):
      2.   # Any change in the my_other_lib version, user or
      3.   # channel or Package ID will affect our package ID
      4.   self.info.requires["my_other_lib"].full_package_mode()
      my_lib/1.0 是一个共享库，需要另一个共享库my_other_lib/2.0 包。当新的my_other_lib/2.1 版本发布时: 我是否需要为my_lib/1.0 创建一个新的二进制文件以与之链接？

    这取决于。 如果公共头文件根本没有更改，则没有必要。 实际上，可能有必要考虑在公共头之间共享的可传递依赖项，它们如何链接以及它们是否跨越API的边界，这也可能导致不兼容。 如果公共标头已更改，则取决于哪些更改以及如何在my_lib/1.0中使用它们。 向公共头添加新方法不会产生任何影响，但是更改从my_lib/1.0编译时将内联的某些函数的实现肯定需要重新构建。 对于这种情况，具有以下配置可能很有意义：

    1. def package_id(self):
    2.     # Any change in the my_other_lib version, user or channel
    3.     # or Package ID will affect our package ID
    4.     self.info.requires["my_other_lib"].full_package_mode()
    6.     # Or any change in the my_other_lib version, user or
    7.     # channel will affect our package ID
    8.     self.info.requires["my_other_lib"].full_recipe_mode()

    my_lib/1.0 是仅头文件库，与my_other_lib/2.0 包中任何类型 (标题、静态、共享) 的库链接。当新的my_other_lib/2.1 版本发布时: 我是否需要为my_lib/1.0 创建一个新的二进制文件以与之链接？
    决不。 程序包应该始终与没有设置，没有选项以及以任何方式影响二进制文件的依赖项相同，因为没有这样的二进制文件。 默认行为应更改为：

    1. def package_id(self):
    2.     self.info.requires.clear()

    my_lib/1.0是一个静态库，它链接到my_other_lib/2.0软件包中的仅标头库。 发布新的my_other_lib/2.1版本时：是否需要为my_lib/1.0创建新的二进制文件才能与其链接？ 可能会发生在某些my_lib头文件中严格使用my_other_lib头文件，这些头文件未经编译但包含在传递中。 但是通常，在MyLib实现文件中更可能使用my_other_lib标头，因此，它们中的每个更改都应暗示要构建一个新的二进制文件。 如果我们知道通道中的更改永远不会暗示源代码更改（按照工作流程/生命周期中的设置），则可以编写：

    1. def package_id(self):
    2.     self.info.requires["my_other_lib"].full_package()
    3.     self.info.requires["my_other_lib"].channel = None # Channel doesn't change out package ID