Ctrl+K

SciPy 核心開發者指南#

決策過程#

SciPy 有正式的治理模型，記錄在 SciPy 專案治理 中。以下章節以非正式的方式記錄了關於程式碼和提交權限決策的實際運作方式。正式的治理模型為主導，以下內容僅供參考。

程式碼#

任何關於新增（或不新增）新功能、破壞向後相容性或對程式碼庫進行其他重大變更的重要決策，都應在 scipy-dev 論壇上經過討論（最好在完全共識下）後做出。

任何非瑣碎的變更（瑣碎意味著錯字或單行維護提交）都必須通過提取請求 (PR) 提交。它必須由另一位開發者審閱。如果審閱沒有及時發生，並且 PR 需要快速合併，則 PR 提交者應向論壇發送訊息，說明他們打算在時間 X 因原因 Y 在沒有審閱的情況下合併該 PR，除非有人在此之前審閱。

變更和新增內容應經過測試。未經測試的程式碼是損壞的程式碼。

提交權限#

誰獲得提交權限由 SciPy 指導委員會決定；提交權限的變更將在 scipy-dev 論壇上公佈。

決定新功能#

到目前為止，接受提議的新功能的一般決策規則取決於以下條件：

  1. 該方法適用於許多領域，並且「普遍認為」有用，

  2. 它符合子模組的主題，並且不需要廣泛的支援框架來運作，

  3. 實作看起來健全，並且不太可能在未來需要太多調整（例如，預期的維護負擔有限），

  4. 有人想要貢獻它，以及

  5. 有人想要審閱它。

最後一個準則通常是提議功能的癥結點。程式碼在經過徹底審閱之前無法合併，並且總是有積壓的維護任務與審閱者的時間競爭。理想情況下，貢獻者應在開始工作之前與具有適當領域專業知識的審閱者聯繫。

雖然很難對「普遍有用且普遍認為可行」的含義給出硬性規定，但權衡以下因素可能會有所幫助：

  • 該方法在實踐中是否在不同領域中使用/有用？正確使用它需要多少特定領域的背景知識？

  • 考慮模組中已有的程式碼。您要新增的內容是否是遺漏？它是否解決了您期望模組能夠解決的問題？它是否以顯著的方式補充了現有的功能？

  • 考慮通常預期的相似方法/功能的等價類別。其中，原則上最小的集合應該是什麼，以便提供的功能中沒有明顯的遺漏？那會是多少東西？包含它們的代表性一個是否涵蓋了大多數用例？原則上，將最小集合中的所有內容都包含在模組中是否聽起來合理？

  • 您要新增的內容在文獻中是否已被充分理解？如果沒有，您有多確定它會進展順利？該方法與其他類似方法相比表現如何？

  • 請注意，一年兩次的發行週期和向後相容性政策使得以後更正問題變得更加困難。

子模組的範圍也各不相同，因此最好將每個子模組視為一個獨立的專案——「特殊函數的數值評估」相對明確，但「常用的最佳化演算法」則不然。

在 GitHub 上開發#

SciPy 開發主要在 GitHub 上進行；本節描述了問題、提取請求和管理主要 scipy 儲存庫的預期工作方式。

標籤和里程碑#

每個問題和提取請求通常至少獲得兩個標籤：一個用於主題或組件（scipy.stats、Documentation 等），另一個用於問題或提取請求的性質（enhancement、maintenance、defect 等）。其他標籤可能會根據情況添加：

  • good-first-issue：適用於新貢獻者處理的問題。

  • needs-work：用於有審閱意見但尚未解決的提取請求。

  • needs-decision：用於需要決策的問題或提取請求。

  • needs-champion：用於原始作者未完成但值得復活的提取請求。

  • backport-candidate：發行經理應考慮向後移植的錯誤修復。

為計劃發行的每個版本號創建一個里程碑。需要解決的問題和需要為特定版本合併的提取請求應設定為相應的里程碑。在提取請求合併後，其里程碑（以及它關閉的問題的里程碑）應設定為下一個即將發行的版本——這使得可以輕鬆地概覽變更，並將完整的變更列表添加到發行說明中。

提取請求審閱工作流程#

在審閱提取請求時，請使用提取請求工作流程功能，請參閱 使用工作流程功能。

處理提取請求#

  • 在合併貢獻時，提交者有責任確保這些貢獻符合 貢獻 SciPy 中概述的要求。另請檢查 scipy-dev 論壇上是否討論過新功能和向後相容性破壞。

  • 新程式碼通過提取請求 (PR) 進入。

  • 使用綠色按鈕合併新程式碼。如果發生合併衝突，請要求 PR 提交者重新定基 (rebase)（這可能需要提供一些 git 指令）。

  • 向後移植和完成 PR 的瑣碎新增內容（真正瑣碎，例如錯字或 PEP8 修復）可以直接推送。

  • 對於新增功能或在某種程度上很複雜的 PR，請至少等待一兩天再合併。這樣，其他人就有機會在程式碼進入之前發表評論。

  • 壓縮您認為過於混亂的 PR 的提交或清理提交訊息是可以的。但請確保在執行此操作時保留原始作者姓名。當提交訊息沒有（大致）遵循 撰寫提交訊息 中的指南時，強烈建議壓縮。

  • 確保正確設定合併 PR 上的標籤和里程碑。

  • 當您想要拒絕 PR 時：如果非常明顯，您可以直接關閉它並解釋原因。如果不明顯，那麼最好先解釋您為什麼認為 PR 不適合包含在 SciPy 中，然後讓第二個提交者評論或關閉。

向後移植#

所有提取請求（無論它們包含增強功能、錯誤修復或其他內容）都應針對 main 分支提交。只有錯誤修復才有可能向後移植到維護分支。SciPy 的向後移植策略是 (a) 僅向後移植重要的修復，以及 (b) 僅在合理確定相關維護分支上將進行新的錯誤修復發行時才向後移植。通常，合併重要錯誤修復的開發者會新增 backport-candidate 標籤並 ping 發行經理，由發行經理決定是否以及何時進行向後移植。向後移植完成後，必須再次移除 backport-candidate 標籤。

向後移植提取請求的一個好策略是組合多個 main 分支提取請求，以減輕持續整合測試的負擔並減少維護分支歷史記錄的合併提交混亂。通常最好為向後移植提取請求中表示的每個 main 分支提取請求使用單個提交。這樣，歷史記錄清晰，並且可以在需要時以直接的方式還原。

發行說明#

當 PR 合併時，請考慮是否需要在發行說明中提及變更。需要提及的內容：新功能、向後不相容的變更、棄用和「其他變更」（任何其他值得注意的內容，請參閱較舊的發行說明，了解值得提及的內容類型）。

發行說明條目維護在 wiki 上。發行經理將從那裡收集內容並將其整合到 html 文檔中。我們使用此機制來避免如果每個 PR 都直接觸碰 doc/release/ 下的同一個檔案而發生的合併衝突。

可以監控變更 (Atom feed) 並拉取（wiki 是一個 git 儲存庫：https://github.com/scipy/scipy.wiki.git）。

其他#

交叉引用： 在 GitHub 上交叉引用問題和提取請求通常很有用。GitHub 允許通過使用 gh-xxxx 或 #xxxx，其中 xxxx 是問題/PR 編號來做到這一點。gh-xxxx 格式是強烈推薦的，因為它清楚地表明這是一個 GitHub 連結。較舊的問題包含 #xxxx，這是關於 Trac（我們在 GitHub 之前使用的）票證。

PR 命名慣例： 提取請求、問題和提交訊息通常以三個字母的縮寫開頭，例如 ENH: 或 BUG:。這有助於快速了解提交/PR/問題的性質。有關縮寫的完整列表，請參閱 撰寫提交訊息。

授權許可#

SciPy 是在 修改後的 (3-條款) BSD 許可證 下發行的。貢獻者新增到 SciPy 的所有程式碼、文檔和其他檔案均根據此許可證授權，除非原始碼中明確指定了其他許可證。貢獻者保留他們編寫並提交以包含在 SciPy 中的程式碼的著作權。

與 SciPy 使用的修改後的 BSD 許可證相容的其他許可證是 2-條款 BSD、MIT 和 PSF。不相容的許可證是 GPL、Apache 和需要署名/引用或禁止用於商業目的的自訂許可證。

PR 通常提交的內容是從未經許可的程式碼或來自與 SciPy 許可證不相容的預設許可證的程式碼複製或衍生而來的。例如，在 StackOverflow 上發佈的程式碼受 CC-BY-SA 許可證保護，由於共享條款，該許可證不相容。除非原始程式碼作者願意根據修改後的 BSD（或相容）許可證（重新）授權他們的程式碼，否則這些貢獻不能被 SciPy 接受。如果原始作者同意，請在原始碼檔案中新增評論說明，並將相關溝通轉發到 scipy-dev 論壇。

另一個常見情況是程式碼從 R、Octave（均為 GPL 許可）或商業應用程式中的程式碼翻譯或衍生而來。此類程式碼也不能包含在 SciPy 中。但是，簡單地實作與 R/Octave/… 中找到的 API 具有相同功能的程式碼是可以的，只要作者不查看原始的不相容許可程式碼即可。

版本編號#

SciPy 版本編號符合 PEP 440。發行的最終版本（這是唯一出現在 PyPI 上的版本）編號為 MAJOR.MINOR.MICRO，其中

  • MAJOR 是一個整數，表示主要版本。它很少更改；MAJOR 的更改表示大型（可能向後不相容）的變更。

  • MINOR 是一個整數，表示次要版本。次要版本通常每年發行兩次，並且可以包含新功能、棄用和錯誤修復。

  • MICRO 是一個整數，表示錯誤修復版本。錯誤修復版本在需要時發行，通常每個次要版本發行一到兩個。它們不能包含新功能或棄用。

發行的 alpha、beta 和 rc（候選發行版）版本的編號方式與最終版本類似，但帶有後綴 a#、b# 和 rc#，其中 # 是一個整數。開發版本以 .dev0+<git-commit-hash> 為後綴。

有效的 SciPy 版本字串範例包括

0.16.0
0.15.1
0.14.0a1
0.14.0b2
0.14.0rc1
0.17.0.dev0+ac53f09

已安裝的 SciPy 版本包含這些版本識別符

scipy.__version__            # complete version string, including git commit hash for dev versions
scipy.version.short_version  # string, only major.minor.micro
scipy.version.version        # string, same as scipy.__version__
scipy.version.full_version   # string, same as scipy.__version__
scipy.version.release        # bool, development or (alpha/beta/rc/final) released version
scipy.version.git_revision   # string, git commit hash from which scipy was built

棄用#

想要移除現有功能的原因有很多：它有錯誤、API 不易理解、它被效能更好的功能取代、它需要移動到另一個 SciPy 子模組等等。

一般來說，在沒有事先警告用戶即將移除的情況下移除某些東西並不是一個好主意。因此，這是從公用 API 中移除某些東西之前應該做的事情：

  1. 在 scipy-dev 論壇上提議棄用該功能，並獲得同意。

  2. 為其新增 DeprecationWarning，說明該功能已棄用，以及在哪個版本中棄用。對於 Cython API，請參閱 棄用公用 Cython API 了解實際步驟。

  3. 在該版本的發行說明中提及棄用。

  4. 在引入 DeprecationWarning 的版本發行日期後，至少等待 6 個月再移除該功能。

  5. 在發行說明中提及移除該功能。

6 個月的等待期在實踐中通常意味著等待兩個版本。在引入警告時，還要確保在執行測試套件時過濾掉這些警告，以免它們污染輸出。

對於特定的棄用，可能有理由想要忽略此棄用政策；這始終可以在 scipy-dev 論壇上討論。

供應商程式碼#

SciPy 程式碼庫的許多部分在其他地方維護，並供應到 SciPy 中。其中一些部分作為 git 子模組供應，例如 boost_math。

其他部分雖然有維護的上游，但並未作為 git 子模組供應。這主要是出於歷史原因，並且這些部分中的一些可能會看到向上游貢獻的補丁，並在未來成為 git 子模組。

維護者應注意不要接受對 SciPy 中程式碼積極在上游維護的部分的貢獻（尤其是瑣碎的變更）。相反，他們應該引導貢獻者訪問上游儲存庫。目前，這包括程式碼庫的以下部分：

  • DIRECT，位於 scipy/optimize/_direct

  • ARPACK，位於 scipy/sparse/linalg/_eigen/arpack/ARPACK

  • SuperLU，位於 scipy/sparse/linalg/_dsolve/SuperLU

  • QHull，位於 scipy/spatial/qhull_src

  • trlib，位於 scipy/optimize/_trlib

  • UNU.RAN，位於 scipy/stats/_unuran

發行#

發行 Python 套件並非易事——尤其是對於像 SciPy 這樣具有複雜建置要求的套件而言——並且可能會發生變化。有關推薦工具和技術的最新概述，請參閱 Python Packaging User Guide。本文檔討論了 SciPy 的一些主要問題和注意事項。

相依性#

相依性是用戶為了使用（或建置/測試）套件而必須安裝的東西。它們通常會引起麻煩，尤其是在它們不是可選的情況下。SciPy 盡量將其相依性保持在最低限度；目前所需的和可選的建置時相依性可以在 SciPy 的設定檔 pyproject.toml 中看到。唯一的非可選運行時相依性是 NumPy。

此外，當然需要 C、C++ 和 Fortran 編譯器來建置 SciPy，但我們不認為這些是相依性，因此在這裡不討論它們。有關詳細資訊，請參閱 從原始碼建置。

當一個套件提供有用的功能並且被提議作為新的相依性時，也要考慮是否將該套件供應（即隨 SciPy 發行其副本）而不是作為相依性。例如，decorator 在 scipy._lib 中供應。

相依性處理的問題#

關於 Python 套件工具如何處理專案報告的相依性，存在一些問題。由於 SciPy 定期收到有關此問題的錯誤報告，因此我們在這裡詳細介紹一下。

SciPy 通過 pyproject.toml 報告其對 NumPy 的相依性以用於建置目的，並且 SciPy 還具有運行時檢查，以確保可使用適當版本的 NumPy。SciPy 不再使用 setup_requires（過去曾調用 easy_install）；建置相依性現在僅通過 pyproject.toml 處理。pyproject.toml 依賴於 PEP 517；pip 具有 --no-use-pep517 和 --no-build-isolation 標誌，這些標誌可能會忽略 pyproject.toml 或以不同的方式處理它——如果用戶使用這些標誌，他們有責任自行安裝正確的建置相依性。

NumPy 和其他相依性的版本範圍#

對於相依性，重要的是設定其版本的下限和上限。對於建置時相依性，它們在 pyproject.toml 中指定，並且版本僅適用於 SciPy 建置本身。為 meson-python 或 pybind11 之類的相依性指定範圍或特定版本都可以。對於 NumPy，我們也必須擔心 ABI 相容性。但是，對於 NumPy >=2.0.0rc1，向後相容性得到保證，最早可追溯到 NumPy 1.19 系列，因此不再需要在 pyproject.toml 中指定建置時支持的最低 NumPy 版本。

對於運行時相依性（目前只有 numpy），我們在 pyproject.toml 和 scipy/__init__.py 中指定版本範圍。正確設定上限有點棘手。如果我們不設定任何上限，幾年後將會拉入一個過於新的版本，並且 NumPy 可能已經棄用並移除了 SciPy 依賴的某些 API。另一方面，如果我們將上限設定為最新的已發行版本，那麼一旦發行新的 NumPy 版本，將沒有與之相容的 SciPy 版本。鑑於 NumPy 和 SciPy 都以 6 個月的頻率發行，並且 NumPy 中棄用的功能應保留約兩個版本，我們將上限指定為 <2.xx+3.0（其中 xx 是最新的已發行 NumPy 的次要版本）。

支援的 Python 和 NumPy 版本#

SciPy 支援的 Python 版本在 pyproject.toml 中的 PyPI 分類器列表中列出，並在每個版本的發行說明中提及。所有新發行的 Python 版本將盡快獲得支援。有關放棄支援 Python 或 NumPy 版本的一般政策，請參閱 NEP 29。關於放棄支援的最終決定始終在 scipy-dev 論壇上做出。

SciPy 版本的最低支援 NumPy 版本在發行說明中提及，並編碼在 pyproject.toml 和 scipy/__init__.py 中。通常，最新的 SciPy 版本支援約 5-7 個 NumPy 次要版本：最舊可達 2.5 年的 NumPy 版本（假設在撰寫本文時 NumPy 發行頻率約為每年 2 次），以及未來兩個版本。

支援的可選相依性和編譯器版本記錄在 工具鏈 Roadmap 中。請注意，並非所有支援的可選相依性版本都經過 SciPy 持續整合設定的良好或完全測試。有關此方面的問題會在問題追蹤器或論壇中出現時處理。

建置二進制安裝程式#

注意

本節僅關於建置 SciPy 二進制安裝程式以進行發行。有關在將要使用的同一台機器上建置 SciPy 的資訊，請參閱 此 scipy.org 頁面。

在建置二進制檔案並將其發行到 PyPI 或其他地方時，需要考慮許多事項。

一般

  • 二進制檔案特定於單個（主要）Python 版本（因為不同的主要 Python 版本不是 ABI 相容的，至少在 Python 3.12 之前是這樣）。

  • 針對 NumPy 2.0.0 建置，然後它將適用於所有具有相同主要版本號的 NumPy 版本（NumPy 確實保持向後 ABI 相容性），並且在撰寫本文時最早可追溯到 NumPy 1.19 系列。

  • 用於建置可移植 SciPy 二進制檔案的最簡單可用工具鏈是我們用於常見平台的 cibuildwheel 基礎架構，詳細資訊可在我們的 CI 基礎架構程式碼中找到，並可通過 Windows、Linux 和 MacOS 上的 cibuildwheel 命令使用，儘管在某些情況下需要一些額外的外部相依性。

Windows

  • 對於使用免費工具鏈建置的 64 位 Windows 安裝程式，請使用 numpy/numpy 中記錄的方法。一旦明確該工具鏈的維護是長期可持續的，該方法很可能會用於 SciPy 本身。有關詳細資訊，請參閱 MingwPy 專案和 此執行緒。

  • 產生 64 位 Windows 安裝程式的另一種方法是使用 icc、ifort 和 MKL（或使用 MSVC 而不是 icc）。有關 Intel 工具鏈的說明，請參閱 本文，有關（部分）MSVC 的說明，請參閱 此 wiki 頁面。

  • 較舊的 SciPy 版本包含 .exe「超級包」安裝程式。這些安裝程式包含 3 個完整的建置版本（無 SSE、SSE2、SSE3），並且是使用 numpy/numpy-vendor 建置的。已知該建置設定不再能很好地工作，並且不再受支援。它使用 g77 而不是 gfortran，這是由於複雜的 DLL 發行問題（參見 gh-2829）。由於工具鏈不再受支援，因此不再需要 g77 支援，並且 SciPy 現在可以包含 Fortran 90/95 程式碼。

Linux

  • 與 PyPI 相容的 Linux wheels 可以通過 manylinux 專案生成，該專案在我們的 cibuildwheel 基礎架構下使用。

其他 Linux 建置設定會產生與 PyPI 不相容的 wheels，這些 wheels 需要通過自訂管道發行，例如在 Wheelhouse 中，請參閱 wheel 和 Wheelhouse 文檔。

製作 SciPy 發行版#

在最高層級，這是發行經理為發行新的 SciPy 版本所做的事情：

  1. 在 SciPy 論壇 https://discuss.scientific-python.org/ 上提出發行時間表。

  2. 為發行版建立維護分支。

  3. 標記發行版。

  4. 建置所有發行產物（原始碼、安裝程式、文檔）。

  5. 上傳發行產物。

  6. 宣佈發行。

  7. 將相關變更移植到發行說明和建置腳本至 main 分支。

在本指南中，我們嘗試詳細描述如何執行上述每個步驟。除了發行經理必須執行的這些步驟外，以下是關於發行相關活動和慣例的說明，供您參考

提議發行時程表#

典型的發行週期如下所示

  • 建立維護分支

  • 發行 Beta 版本

  • 發行「候選發行版本」(RC)

  • 如果需要，發行一個或多個新的 RC

  • 一旦最後一個候選發行版本沒有問題，就發行最終版本

上述每個步驟之間通常至少間隔一週。經驗顯示，新次要版本的週期需要 4 到 8 週。錯誤修復版本不需要 Beta 或 RC，可以更快完成。

理想情況下，最終版本應與最後一個 RC 完全相同，但可能存在細微差異——這取決於發行經理來判斷風險。通常，如果編譯程式碼或複雜的純 Python 程式碼發生變更，則需要新的 RC，而從 main 分支向後移植的簡單錯誤修復則不需要新的 RC。

若要提議時程表，請將包含分支和 Beta/RC/最終發行版本的預估日期的清單發送到 SciPy 論壇：https://discuss.scientific-python.org/。在同一訊息中，請要求所有人檢查是否有重要的問題/PR 需要包含但未標記發行版本的里程碑或「backport-candidate」標籤。

建立維護分支#

在分支之前，請確保發行說明已盡可能更新。在發行說明中包含 tools/gh_lists.py 和 tools/authors.py 的輸出。

維護分支命名為 maintenance/<major>.<minor>.x (例如 0.19.x)。若要建立一個，只需將具有正確名稱的分支推送到 scipy 儲存庫。緊接著，推送一個提交，在其中增加 main 分支上的版本號，並為該新版本新增發行說明。發送電子郵件至 SciPy 論壇：https://discuss.scientific-python.org/，告知大家您已完成此操作。

更新版本切換器#

版本切換器下拉選單需要使用 main 分支上的新發行資訊進行更新。

  • doc/source/_static/version_switcher.json：新增新發行版本、新的開發版本，並將 "preferred": true 從舊發行版本轉移到新發行版本。

更新相依性的上限#

在 main 分支中，我們不設定上限，因為我們想要在那裡測試新的發行版本或相依性的開發版本。然而，在維護分支中，目標是能夠建立可以在多年內保持運作的發行版本。因此，必須設定正確的上限。建立維護分支後，必須更新以下位置

  • pyproject.toml：所有建置時期的相依性，以及支援的 Python

    和 NumPy 版本

  • scipy/__init__.py：用於 NumPy 版本檢查

每個檔案都有註解，說明如何設定正確的上限。

標記發行版本#

首先，請確保您已正確設定 GPG。請參閱 scipy/scipy#4919 以了解簽署發行標籤的討論，並參閱 https://keyring.debian.org/creating-key.html 以取得關於建立 GPG 金鑰的說明 (如果您沒有金鑰)。請注意，在某些平台上，使用 gpg2 而不是 gpg 可能更合適，以便密碼可以由 gpg-agent 儲存，如 scipy/scipy#10189 中所述。在遠端準備發行版本時，可能需要在 ~/.gnupg/gpg-agent.conf 中設定 pinentry-mode loopback，因為 gpg2 的使用否則將透過無法存取的圖形密碼提示進行。

為了讓您的金鑰更容易識別為您，請考慮將您的金鑰發送到公開金鑰伺服器，並使用如下命令

gpg --send-keys <yourkeyid>

檢查所有相關的提交是否都在分支中。特別是，檢查發行版本的里程碑 (scipy/scipy) 下的問題和 PR、「backport-candidate」標籤的 PR，以及發行說明是否為最新且包含在 html 文件中。

然後，更新 pyproject.toml 中的 version，並使用類似 REL: set version to <version-number> 的訊息提交變更。請勿立即將此提交推送到 SciPy 儲存庫。

最後，使用 git tag -s <v1.x.y> 在本機標記發行版本 ( -s 確保標籤已簽署)。如果偏好 gpg2，則 git config --global gpg.program gpg2 可能適用。繼續進行建置發行版本成品 (下一節)。僅在您成功建置 sdist 和文件後，才將發行提交推送至 scipy 儲存庫。然後繼續建置 wheel。僅在 TravisCI 和 Appveyor 上成功建置所有 wheel 後，才將發行標籤推送至儲存庫 (如果失敗，您必須移動標籤，否則這是不良做法)。最後，在推送標籤後，也推送第二個提交，該提交會增加版本號並為 version: 附加 .dev0，並再次將 ISRELEASED 設定為 False。這也適用於新的候選發行版本，以及在從候選發行版本切換到正式發行版本時移除 rc 字尾。

建置發行版本成品#

以下是為發行版本建立的完整成品清單

  • sdist (scipy-x.y.y.tar.gz，適用於 PyPI 和 GitHub Releases)

  • Windows、Linux 和 macOS 的二進位 wheel

  • 文件 (html)

  • README.txt 檔案

  • Changelog 檔案

sdist 是透過執行 python -m build --sdist 產生的 (注意：我們仍然需要將其移至 CI 作業！)，而 Changelog 和 README 是透過在儲存庫根目錄中執行 python dev.py notes (使用標籤，請參閱 python dev.py notes --help) 建置的，並最終位於 REPO_ROOT/release/ 中。在您在本機建立簽署標籤後執行此操作。如果順利完成，請將發行提交 (而非標籤，請參閱上方章節) 推送至 scipy 儲存庫。

若要建置 wheel，請將包含文字 [wheel build] 的提交推送到用於目前發行版本的分支。這會觸發 cibuildwheel 建置，適用於所有需要的 Python 版本和平台。NumPy 和其他相依性的適當版本釘選應已在分支後立即在 pyproject.toml 中更新。如果 wheel 建置顯示需要透過維護分支上的向後移植來修復的問題，您可以移除本機標籤 (例如 git tag -d v1.2.0rc1)，並使用上述標記重新開始新的候選提交。

cibuildwheel 基礎架構會從建置的 wheel 執行測試，如果測試通過，則將 wheel 上傳至 https://anaconda.org/multibuild-wheels-staging/scipy。

您可以從那裡下載它們，以便上傳到 PyPI。這可以使用 tools/download-wheels.py 以自動化方式完成

$ python tools/download-wheels.py 1.5.0rc1 -w REPO_ROOT/release/installers

在此之後，我們想要重新產生 README 檔案，以便在其中包含剛下載的 wheel 的 MD5 和 SHA256 總和檢查碼。再次執行 python dev.py notes。

上傳發行版本成品#

對於發行版本，目前有五個網站可以上傳內容

  • PyPI (sdist、wheel)

  • GitHub Releases (sdist、發行說明、Changelog)

  • scipy.org (發行公告)

  • docs.scipy.org (html 文件)

PyPI

先上傳 wheel，然後上傳 sdist

twine upload REPO_ROOT/release/installers/*.whl
twine upload REPO_ROOT/release/installers/scipy-1.x.y.tar.gz

Github Releases

在 scipy/scipy 上使用 GUI 建立發行版本並上傳所有發行版本成品。在此階段，適合推送標籤並在 GUI 中將新發行版本 (候選版本) 與此標籤關聯。例如，git push upstream v1.2.0rc1，其中 upstream 代表 scipy/scipy。檢查先前的發行版本以確定應在 GUI 上傳過程中包含哪些成品非常有用。另請注意，發行說明不會自動填入 GitHub 上的發行版本描述中，並且一些手動重新格式化為 markdown 可能非常有助於符合網站上先前發行版本的格式。我們通常不會在這些 GUI 描述中包含 Issue 和 Pull Request 清單。

scipy.org

網站的來源位於 scipy/scipy.org。透過 PR 更新 content/en/news.md 中的 News 章節。這僅適用於正式發行版本，不適用於候選發行版本。

docs.scipy.org

首先建置 scipy 文件，方法是在 scipy/doc/ 中執行 make dist。驗證它們看起來是否正常，然後使用 make upload USERNAME=rgommers RELEASE=0.19.0 將它們上傳到文件伺服器。請注意，需要 SSH 存取文件伺服器；如果您沒有存取權限，請詢問 @pv (伺服器管理員)、@tylerjereddy 或 @rgommers (可以上傳)。

網站本身的來源維護在 scipy/docs.scipy.org 中。在 index.rst 的發行版本表格中新增新的 SciPy 版本。推送該提交，然後執行 make upload USERNAME=yourusername。這僅適用於正式發行版本，不適用於候選發行版本。

總結#

向 https://discuss.scientific-python.org/c/announcements/ 發送訊息，宣布發行版本。

對於 Beta 和 RC 版本，請要求人們測試 (執行 scipy 測試並針對他們自己的程式碼進行測試) 並在 Github 或 Discourse 上報告問題。

在最終版本完成後，將相關變更移植到發行說明、建置腳本、tools/authors.py 中的作者名稱對應以及僅在維護分支上進行的任何其他變更至 main 分支。

透過編輯發行伺服器上上傳文件根資料夾中的執行階段設定檔 try_examples.json，啟用互動式範例。必須從 ignore_patterns 清單中移除正則表達式模式 ".*"。

$ ssh your-username@docs.scipy.org
$ cd /srv/docs_scipy_org/doc/scipy-1.13.1
$ vim try_examples.json  # edit the ignore list to remove: ".*"
在本頁中