SciPy 核心开发者指南#

决策流程#

SciPy 拥有一个正式的治理模式，在 SciPy 项目治理 中有记录。以下部分以非正式的方式记录了在实践中关于代码和提交权限的决策是如何进行的。正式的治理模式是主要的，以下内容仅供参考。

代码#

任何关于添加（或不添加）新功能、破坏向后兼容性或对代码库进行其他重大更改的重大决定，都应在 scipy-dev 论坛上经过讨论（最好达成共识）后做出。

任何非微不足道的更改（其中微不足道是指拼写错误或单行维护提交）都必须通过拉取请求 (PR) 进行。它必须由另一位开发者进行审查。如果审查没有及时完成，并且 PR 需要快速合并，则 PR 提交者应向论坛发送消息，说明他们打算在时间 X 将该 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 标签。

反向移植拉取请求的一个好策略是将多个主分支拉取请求合并在一起，以减少对持续集成测试的负担，并减少维护分支历史记录中的合并提交混乱。通常最好为反向移植拉取请求中表示的每个主分支拉取请求有一个单独的提交。这样，历史记录就很清晰，如果需要，可以以简单的方式进行回滚。

发行说明#

当 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 许可证的保护，由于共享相似条款，它与 SciPy 不兼容。这些贡献不能被接受包含在 SciPy 中，除非原始代码作者愿意以修改后的 BSD（或兼容）许可证为其代码重新授权。如果原始作者同意，请在源文件中添加一条评论，并向 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 子模块提供，尽管它们在 upstream 有维护。这主要是出于历史原因，这些部分中的一些部分可能会在将来看到 upstream 的补丁贡献，并成为 git 子模块。

维护者应注意，不要接受对 SciPy 中代码在 upstream 被积极维护的部分的贡献（尤其是微不足道的更改）。相反，他们应该将贡献者引导到 upstream 存储库。目前，这包括代码库的以下部分

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

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

  • QHull，位于 scipy/spatial/qhull

  • trlib，位于 scipy/optimize/_trlib

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

分发#

分发 Python 包并非易事，尤其是对于像 SciPy 这样具有复杂构建要求的包而言，并且会发生变化。有关推荐工具和技术的最新概述，请参见 Python 包装用户指南。本文档讨论了 SciPy 的一些主要问题和注意事项。

依赖项#

依赖项是用户必须安装才能使用（或构建/测试）软件包的东西。它们通常会导致问题，尤其是在它们不是可选的情况下。SciPy 试图将其依赖项保持在最低限度；当前的必需和可选构建时依赖项可以在 SciPy 的配置文件、pyproject.toml 中看到。唯一不是可选的运行时依赖项是 NumPy。

此外，当然需要 C、C++ 和 Fortran 编译器来构建 SciPy，但我们不认为它们是依赖项，因此此处不讨论它们。有关详细信息，请参见 从源代码构建。

当软件包提供有用的功能，并且被提议为新的依赖项时，也要考虑是否将该软件包作为供应商提供（即与 SciPy 一起提供）。例如，decorator 在 scipy._lib 中作为供应商提供。

依赖项处理问题#

Python 包装工具在处理项目报告的依赖项方面存在一些问题。由于 SciPy 定期收到关于此的错误报告，因此我们将在此处详细介绍。

SciPy 仅在系统上根本没有安装 NumPy 时，或者使用 bdist_wheel 构建 wheel 时，通过 install_requires 报告其对 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 本身。为依赖项（如 wheel 或 setuptools）指定范围或特定版本都可以。对于 NumPy，我们还必须担心 ABI 兼容性，因此我们使用 == 将版本指定为最低支持版本（因为 NumPy 的 ABI 向后兼容，但向前不兼容）。

对于运行时依赖项（目前仅 numpy），我们在 pyproject.toml 和 setup.py 中的 install_requires 中指定版本范围。正确获得上限有点棘手。如果我们不设置任何上限，那么几年后将引入一个过新的版本，并且 NumPy 可能已经弃用并删除了 SciPy 当时依赖的一些 API。另一方面，如果我们将上限设置为最新的已发布版本，那么一旦发布了新的 NumPy 版本，就将没有与之匹配的 SciPy 版本。考虑到 NumPy 和 SciPy 都以 6 个月为周期发布，并且在 NumPy 中被弃用的功能应该保留另外两个版本，因此我们将上限指定为 <1.xx+3.0（其中 xx 是最新的已发布 NumPy 的次版本）。

支持的 Python 和 NumPy 版本#

SciPy 支持的 Python 版本列在 setup.py 中的 PyPI 分类器列表中，并且在每个版本的发布说明中都有提及。所有新发布的 Python 版本将在尽可能短的时间内得到支持。有关停止支持 Python 或 NumPy 版本的通用策略，请参见 NEP 29。最终的停止支持决定将始终在 scipy-dev 论坛上做出。

某个 SciPy 版本支持的最低 Numpy 版本在发布说明中提及，并且在 pyproject.toml、scipy/__init__.py 和 setup.py 的 install_requires 字段中编码。通常，最新的 SciPy 版本支持大约 5-7 个 NumPy 的次要版本：最多 2.5 年前的 NumPy 版本（假设 NumPy 发布频率在撰写本文时约为每年 2 次），再加上两个未来版本。

可选依赖项和编译器的支持版本在 工具链路线图 中有记录。请注意，并非所有支持的可选依赖项版本都经过 SciPy 的持续集成设置的良好测试或根本没有经过测试。有关此问题的任何问题将在问题跟踪器或论坛中出现时处理。

构建二进制安装程序#

注意

本节仅介绍构建 SciPy 二进制安装程序以供分发。有关在同一台机器上构建 SciPy 及其使用位置的信息，请参见 scipy.org 页面。

在构建二进制文件并在 PyPI 或其他地方分发它们时，需要考虑许多因素。

一般

  • 二进制文件特定于单个 Python 版本（因为不同的 Python 版本不兼容 ABI，至少在 Python 3.4 之前是这样）。

  • 针对需要支持的最低 NumPy 版本进行构建，然后它将适用于所有具有相同主要版本号的 NumPy 版本（NumPy 保持向后 ABI 兼容性）。

  • 构建可移植 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 轮子可以通过 manylinux 项目生成，该项目在我们的 cibuildwheel 基础设施下使用。

其他 Linux 构建设置会导致与 PyPI 不兼容的轮子，这些轮子需要通过自定义渠道分发，例如在 Wheelhouse 中分发，请参见 wheel 和 Wheelhouse 文档。

发布 SciPy#

在最高级别，这是发布经理发布新 SciPy 版本的操作。

  1. 在 SciPy 论坛 https://discuss.scientific-python.org/ 上提出发布计划。

  2. 为发布创建维护分支。

  3. 标记发布。

  4. 构建所有发布工件（源代码、安装程序、文档）。

  5. 上传发布工件。

  6. 宣布发布。

  7. 将相关更改移植到发布说明和构建脚本中。

本指南尝试详细描述如何执行上述每个步骤。除了发布经理必须执行的这些步骤之外，这里还描述了与发布相关的活动以及感兴趣的约定。

提出发布计划#

典型的发布周期如下所示

  • 创建维护分支

  • 发布测试版

  • 发布“候选发布版”（RC）

  • 如果需要，发布一个或多个新的 RC

  • 一旦最后一个候选发布版没有问题，就发布最终版本。

上述每个步骤之间通常至少有一周的时间。经验表明，新次要版本需要 4 到 8 周的时间。错误修复版本不需要测试版或 RC，并且可以更快地完成。

理想情况下，最终发布版与最后一个 RC 相同，但可能存在细微差异 - 由发布经理判断这种风险。通常，如果已编译代码或复杂的纯 Python 代码更改，则需要新的 RC，而从主分支移植的简单错误修复则不需要新的 RC。

要提出发布计划，请将分支和测试版/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 存储库即可。立即之后，推送一个提交，在其中将主分支上的版本号递增，并为该新版本添加发布说明。向 SciPy 论坛 https://discuss.scientific-python.org/ 发送一封电子邮件，告知大家您已经执行了此操作。

更新版本切换器#

版本切换器下拉菜单需要在 main 分支上更新新的发布信息。

  • doc/source/_static/version_switcher.json：添加新发布版、新的开发版本，并将 "preferred": true 从旧发布版转移到新发布版。

更新依赖项的上限#

在主分支中，我们不设置上限，因为我们希望在那里测试依赖项的新版本或开发版本。但是，在维护分支中，目标是能够创建能够在数年内保持工作状态的发布版。因此，必须设置正确的上限。创建维护分支后，必须更新以下位置。

  • pyproject.toml：所有构建时依赖项，以及支持的 Python

    和 NumPy 版本

  • scipy/__init__.py：用于 NumPy 版本检查

每个文件都有注释描述如何设置正确の上限。

标记发布#

首先确保您已正确设置 GPG。有关签署发布标签的讨论，请参见 scipy/scipy#4919，有关创建 GPG 密钥的说明（如果您没有），请参见 https://keyring.debian.org/creating-key.html。请注意，在某些平台上，使用 gpg2 而不是 gpg 可能更合适，以便可以通过 gpg-agent 存储密码，如 scipy/scipy#10189 中所述。在远程准备发布时，可能需要在 ~/.gnupg/gpg-agent.conf 中设置 pinentry-mode loopback，因为否则使用 gpg2 将通过无法访问的图形密码提示进行。

为了使您的密钥更容易被识别为您，请考虑将您的密钥发送到公共密钥服务器，使用以下命令：

gpg --send-keys <yourkeyid>

检查所有相关提交都在分支中。特别是，检查发布里程碑下的问题和 PR（scipy/scipy）、标记为“backport-candidate”的 PR，以及发布说明是否已更新并包含在 html 文档中。

然后编辑 meson.build 和 tools/version_utils.py 以获得正确的版本号（在前者中设置 version:，在后者中设置 ISRELEASED = True）。还需要调整 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 仓库。然后继续构建 wheels。只有在 TravisCI 和 Appveyor 上成功构建所有 wheels 后，才将发布标记推送到仓库（如果失败，则必须移动标记，否则将是错误的做法）。最后，在推送标记后，还要推送一个额外的提交，将版本号加一并为 version: 追加 .dev0，并将 ISRELEASED 重新设置为 False。这也适用于新的发布候选版本，以及从发布候选版本切换到正式发布时删除 rc 后缀。

构建发布工件#

以下是为发布创建的所有工件的完整列表

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

  • Windows、Linux 和 macOS 的二进制 wheels

  • 文档（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 仓库。

要构建 wheels，请将包含文本 [wheel build] 的提交推送到用于当前版本的 branch。这将触发 cibuildwheel 为所有需要的 Python 版本和平台构建。NumPy 和其他依赖项的相应版本固定应在分支后立即更新到 pyproject.toml 中。如果 wheel 构建中出现需要在维护 branch 上进行 backports 修复的问题，您可以删除本地标记（例如 git tag -d v1.2.0rc1）并从上面标记新的候选提交开始。

cibuildwheel 基础设施会运行构建的 wheels 中的测试，如果通过，则会将 wheels 上传到 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 文件，以便其中包含刚刚下载的 wheels 的 MD5 和 SHA256 校验和。再次运行 python dev.py notes。

上传发布工件#

对于发布，目前有五个地方可以上传内容

  • PyPI (sdist, wheels)

  • GitHub Releases (sdist, 发布说明，Changelog)

  • scipy.org (发布公告)

  • docs.scipy.org (html 文档)

PyPI

首先上传 wheels，然后上传 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 描述中包含问题和拉取请求列表。

scipy.org

网站的源代码位于 scipy/scipy.org 中。通过 PR 更新 content/en/news.md 中的新闻部分。这仅适用于正式发布，不适用于发布候选版本。

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 中的作者姓名映射以及仅在维护 branch 上进行的其他任何更改。

本页内容