自动部署的 ABI 迁移

对于 Conda-Forge 来说，处理应用程序二进制接口 (ABI) 迁移一直是一件麻烦事。 保持 ABI 一致性有助于为我们的许多用户实现“只需使用 conda-forge”的体验，确保 numpy 的 blas 与 scipy 的相同。 随着库更新其代码，新版本可能与 ABI 不兼容，因为函数签名和其他符号可能已更改，从而导致可怕的 SegmentationFault 和其他错误。

Conda-Forge 通过拥有一个跟踪所有当前支持的 ABI 的 pinning 文件来处理这个问题。 然后，这些 pinned ABI 用于构建下游软件包，确保所有软件包都一致。 随着新版本的 pinned 软件发布，pins 会更新，从而导致 pin 的迁移，以及重新构建所有依赖于 pinned 软件包的软件包。 过去，这是通过更改全局 pinnings 以及随后通过 auto-tick 机器人进行迁移来处理的。 虽然这种方法有效，但它也带来了一些问题。 首先，这种方法可能会导致新软件包无法满足构建依赖项，因为某些新软件包的依赖项已使用新的 pins 编译，但并非全部。 其次，迁移是串行发生的，如果在第一次迁移正在进行时移动了第二个 pin，则迁移可能会出错，因为正在为第一个 pin 重建的软件包在准备好之前获得了第二个 pin。

Conda-Forge Core 最近批准了 CFEP-9，这是一项旨在解决这些问题的迁移策略。 根据 CFEP-9，pinnings 以包含新 pins 的小型 yaml 代码段的形式提出。 然后，auto-tick 机器人开始按顺序迁移软件包，依次将 yaml 代码段应用于每个软件包。 如果发布了第二个 pinning 更改，则机器人也会开始迁移该软件包，从而使两个迁移可以独立工作。 如果一个软件包需要更改两个 pins，则维护人员可以通过先合并一个 pin 再合并另一个 pin 来选择应用 pins 的顺序。

这种方法将在迁移中产生更大的稳定性，并将使更多维护人员能够发布迁移。 可以通过将 PR 放入 conda-forge/conda-forge-pinning-feedstock，并将文件添加到 migrations 文件夹来发布迁移，不再需要向 auto-tick 机器人提交 PR。