自動部署 ABI 遷移

處理應用程式二進位介面 (ABI) 遷移一直是 Conda-Forge 的一個麻煩事。維持 ABI 一致性有助於為我們的許多使用者實現「直接使用 conda-forge」的體驗，確保 numpy 的 blas 與 scipy 的相同。隨著函式庫更新其程式碼，新版本可能與 ABI 不相容，因為函式簽章和其他符號可能已變更，從而導致可怕的 SegmentationFault 和其他錯誤。

Conda-Forge 透過使用釘選檔案來處理此問題，該檔案追蹤所有目前支援的 ABI。這些釘選的 ABI 隨後用於建置下游套件，確保所有套件都一致。隨著釘選軟體的新版本發布，釘選會被更新，導致釘選遷移，以及重建所有依賴釘選套件的套件。過去，這透過變更全域釘選和隨後透過自動勾選機器人進行遷移來處理。雖然這有效，但由此產生了一些問題。首先，這種方法可能會導致新套件的建置相依性無法滿足，因為某些新套件的相依性已使用新釘選編譯，但並非全部。其次，遷移是依序發生的，如果在第一次遷移正在進行時移動了第二個釘選，那麼遷移可能會出錯，因為正在為第一個釘選重建的套件在準備就緒之前就獲得了第二個釘選。

Conda-Forge 核心團隊最近批准了 CFEP-9，這是一個用於解決這些問題的遷移政策。根據 CFEP-9，釘選以包含新釘選的小型 yaml 片段形式提出。然後，自動勾選機器人開始依序遷移套件，依序將 yaml 片段應用於每個套件。如果發布了第二個釘選變更，則機器人也會開始該套件的遷移，從而使兩個遷移能夠獨立運作。如果一個套件需要同時變更兩個釘選，則維護者可以透過在另一個釘選之前合併一個釘選來選擇應用釘選的順序。

這種方法將在遷移中產生更大的穩定性，並將使更多維護者能夠發布遷移。可以透過將 PR 放入 conda-forge/conda-forge-pinning-feedstock，將檔案新增至 migrations 資料夾來發布遷移，不再需要向自動勾選機器人發送 PR。