Ctrl+K

SciPy 核心开发者指南#

决策过程#

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

代码#

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

任何非琐碎的更改（琐碎是指拼写错误或单行维护提交）都必须通过拉取请求 (PR) 进行。它必须由另一位开发者进行审查。如果审查没有及时进行，并且 PR 需要尽快合并，则 PR 的提交者应向邮件列表发送消息，说明他/她打算在时间 X 之前合并该 PR，理由是 Y，除非有人在此之前进行审查。

应测试更改和新增内容。未经测试的代码就是有问题的代码。

提交权限#

SciPy 指导委员会决定谁拥有提交权限；提交权限的更改将在 scipy-dev 邮件列表中公布。

决定新功能#

迄今为止，接受拟议新功能的一般决策规则是：

  1. 该方法适用于许多领域，并且“普遍认为”有用，

  2. 它符合子模块的主题，并且不需要广泛的支持框架来运行，

  3. 实现看起来合理，并且不太可能在将来需要太多调整（例如，预计的维护负担有限），

  4. 有人愿意贡献它，并且

  5. 有人愿意审查它。

最后一个标准通常是拟议功能的症结所在。代码必须经过彻底审查才能合并，而且始终存在维护任务积压，这些任务会争夺审查人员的时间。理想情况下，贡献者应该在开始工作之前找到一位具有合适领域专业知识的审查人员。

虽然很难给出关于“普遍有用且普遍认为有效”的硬性规则，但权衡以下因素可能会有所帮助：

  • 该方法在实践中是否在不同的领域使用/有用？正确使用它需要多少领域特定的背景知识？

  • 考虑模块中已有的代码。您添加的内容是遗漏吗？它是否解决了您期望模块能够解决的问题？它是否以显著的方式补充了现有功能？

  • 考虑通常期望的类似方法/功能的等价类。在它们之中，原则上最小的集合是什么，这样就不会遗漏提供的功能？那会有多少东西？包含其中一个代表性的东西是否涵盖了大多数用例？原则上，将最小集合中的所有内容都包含在模块中是否合理？

  • 您添加的内容是文献中已知的吗？如果不是，您对它是否会成功有多大把握？该方法与其他类似方法相比，性能如何？

  • 请注意，每半年一次的发布周期和向后兼容性策略使得以后更难纠正问题。

子模块的范围也各不相同，因此最好将每个子模块视为一个独立的项目 - “特殊函数的数值评估”定义相对明确，但“常用优化算法”则不然。

GitHub 上的开发#

SciPy 的开发主要在 GitHub 上进行；本节介绍了处理问题、拉取请求和管理主 scipy 存储库的预期工作方式。

标签和里程碑#

每个问题和拉取请求通常至少有两个标签：一个用于主题或组件 (scipy.stats, Documentation 等)，另一个用于问题的性质或拉取请求 (enhancement, maintenance, defect 等)。根据情况，可能会添加其他标签

  • easy-fix: 用于适合新贡献者处理的问题。

  • needs-work: 用于尚未解决审查意见的拉取请求。

  • needs-decision: 用于需要决策的问题或拉取请求。

  • needs-champion: 用于未由原始作者完成但值得恢复的拉取请求。

  • backport-candidate: 应由发布经理考虑回溯的错误修复。

为每个计划发布的版本号创建一个里程碑。需要解决的问题和需要合并到特定版本的拉取请求应设置为相应的里程碑。拉取请求合并后，其里程碑（以及它关闭的问题的里程碑）应设置为下一个即将发布的版本 - 这使得轻松地概述更改并向发布说明中添加完整的更改列表变得容易。

拉取请求审查工作流程#

审查拉取请求时，请使用拉取请求工作流程功能，请参阅 使用工作流程功能.

处理拉取请求#

  • 合并贡献时，提交者有责任确保这些贡献符合 为 SciPy 做贡献 中概述的要求。还要检查新的功能和向后兼容性中断是否在 scipy-dev 邮件列表中进行了讨论。

  • 新代码通过拉取请求 (PR) 进行。

  • 使用绿色按钮合并新代码。如果出现合并冲突，请要求 PR 提交者重新设置基线（这可能需要提供一些 git 指令）。

  • 可以直接推送回溯和微不足道的添加以完成 PR（非常微不足道，例如打字错误或 PEP8 修复）。

  • 对于添加新功能或以某种方式复杂的 PR，请至少等待一两天再合并。这样，其他人就有机会在代码投入使用之前发表评论。

  • 压缩提交或清理您认为过于混乱的 PR 的提交消息是可以的。但是，请确保在执行此操作时保留原始作者姓名。

  • 确保已正确设置合并的 PR 上的标签和里程碑。

  • 当您要拒绝 PR 时：如果非常明显，您可以直接关闭它并解释原因，如果不明确，最好先解释您认为 PR 不适合包含在 SciPy 中的原因，然后让第二个提交者评论或关闭。

回溯#

所有拉取请求（无论它们包含增强功能、错误修复还是其他内容），都应针对 main 进行。只有错误修复才能作为回溯到维护分支的候选。SciPy 的回溯策略是 (a) 仅回溯重要的修复，以及 (b) 仅在合理确定相关维护分支上将发布新的错误修复版本时才回溯。通常，合并重要错误修复的开发人员会添加 backport-candidate 标签并 ping 发布经理，发布经理决定是否以及何时进行回溯。回溯完成后，必须再次删除 backport-candidate 标签。

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

发行说明#

当 PR 被合并时，请考虑是否需要在发布说明中提及更改。需要提及的内容包括：新功能、向后不兼容的更改、弃用以及“其他更改”（任何其他值得注意的更改，请参阅旧的发布说明以了解值得提及的内容）。

发布说明条目在维基上维护（例如，scipy/scipy）。发布经理将从那里收集内容并将其集成到 html 文档中。我们使用这种机制来避免如果每个 PR 直接触及 doc/release/ 下的同一个文件，就会发生的合并冲突。

更改可以被监控 (Atom feed) 并拉取（维基是一个 git 仓库：https://github.com/scipy/scipy.wiki.git）。

其他#

PR 状态页面：当新的提交被添加到拉取请求时，GitHub 不会发送任何通知。尽管如此，needs-work 标签可能不再合理。 此页面 提供了已更新、需要审查、需要决定等的 PR 的概述。

交叉引用：在 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

弃用#

有多种原因会导致我们想要移除现有的功能：存在 bug、API 不易理解、被性能更好的功能取代、需要迁移到其他 SciPy 子模块等。

通常情况下，在不事先通知用户的情况下移除功能并不是一个好主意。因此，在移除公共 API 中的功能之前，应该执行以下操作：

  1. 在 scipy-dev 邮件列表中提出弃用该功能的建议，并获得同意。

  2. 添加 DeprecationWarning，说明该功能已弃用，以及弃用的版本。对于 Cython API，请参阅 弃用公共 Cython API，了解具体的步骤。

  3. 在该版本的发布说明中提及弃用。

  4. 在引入 DeprecationWarning 的版本发布日期后至少等待 6 个月，再移除该功能。

  5. 在发布说明中提及移除该功能。

实际上，6 个月的等待期通常意味着等待两个版本。在引入警告时，还要确保在运行测试套件时过滤掉这些警告，以免污染输出。

对于某些特定的弃用，可能存在需要忽略此弃用策略的原因；这始终可以在 scipy-dev 邮件列表中进行讨论。

分发#

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

依赖项#

依赖项是指用户为了使用（或构建/测试）包而必须安装的东西。它们通常会造成麻烦，尤其是当它们不是可选的时候。SciPy 试图将依赖项保持在最低限度；目前它们是

无条件运行时依赖项

条件运行时依赖项

  • pytest（用于运行测试套件）

  • asv（用于运行基准测试）

  • matplotlib（用于某些可以生成绘图的函数）

  • pooch（用于 scipy.datasets 模块）

  • Pillow（用于图像加载/保存）

  • scikits.umfpack（可选地用于 sparse.linalg）

  • mpmath（用于 special 中的更扩展的测试）

  • pydata/sparse（scipy.sparse 中的兼容性支持）

  • threadpoolctl（用于在测试套件中控制 BLAS/LAPACK 线程）

  • Hypothesis（用于运行某些单元测试）

无条件构建时依赖项

条件构建时依赖项

当然，还需要 C、C++ 和 Fortran 编译器来构建 SciPy，但我们不认为这些是依赖项，因此在此不讨论。有关详细信息，请参阅 https://scipy.github.io/devdocs/dev/contributor/building.html。

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

唯一报告给 pip 的依赖项是 NumPy，请参阅 SciPy 主 setup.py 中的 install_requires。其他依赖项对于 SciPy 正确运行不是必需的。

依赖项处理问题#

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

SciPy 仅在系统上根本没有安装 NumPy 或使用 bdist_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 说明，请参阅 此维基页面。

  • 较旧的 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-dev 邮件列表中提出发布计划。

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

  3. 标记发布。

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

  5. 上传发布工件。

  6. 宣布发布。

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

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

建议发布计划#

典型的发布周期如下

  • 创建维护分支

  • 发布测试版

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

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

  • 当最后一个候选发布版没有问题时，发布最终版本

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

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

要建议发布计划，请向 scipy-dev 发送一个包含分支和测试版/rc/最终版本预计日期的列表。在同一封电子邮件中，请大家检查是否有重要的问题/PR 需要包含，但没有标记为发布的里程碑或“回溯候选”标签。

创建维护分支#

在分支之前，请确保发布说明尽可能更新。在发布说明中包含 tools/gh_lists.py 和 tools/authors.py 的输出。

维护分支命名为 maintenance/<major>.<minor>.x（例如 0.19.x）。要创建一个，只需将一个具有正确名称的分支推送到 scipy 仓库。之后立即，推送一个提交，在主分支上增加版本号，并为该新版本添加发布说明。向 scipy-dev 发送一封电子邮件，告知大家您已完成此操作。

更新版本切换器#

需要使用新的发布信息更新版本切换器下拉菜单。

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

更新依赖项的上限#

在主分支中，我们不设置上限，因为我们希望在那里测试依赖项的新版本或开发版本。然而，在维护分支中，目标是能够创建能够运行多年的版本。因此，必须设置正确の上限。创建维护分支后，以下位置必须更新

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

    和 NumPy 版本

  • setup.py: 支持的 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>

检查所有相关的提交是否都在分支中。特别是，检查里程碑下发布的 Issue 和 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 可能更合适。继续构建发布工件（下一节）。只有在成功构建 sdists 和文档后，才将发布提交推送到 scipy 仓库。然后继续构建 wheels。只有在 TravisCI 和 Appveyor 上成功构建所有 wheels 后，才将发布标签推送到仓库（如果失败，则必须移动标签，这是一种不好的做法）。最后，在推送标签后，还要推送第二个提交，该提交会增加版本号并在 version: 后追加 .dev0，并将 ISRELEASED 重新设置为 False。这同样适用于新的发布候选版本，以及在从发布候选版本切换到正式发布时删除 rc 后缀。

构建发布工件#

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

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

  • Windows、Linux 和 macOS 的二进制轮子

  • 文档 (html)

  • 一个 README.txt 文件

  • 一个 Changelog 文件

通过运行 python -m build --sdist 生成一个 sdist (注意：我们还需要将其移到 CI 任务中！)，并且通过在仓库根目录中运行 python dev.py notes (带有标签，参见 python dev.py notes --help) 来构建 Changelog 和 README，最终结果位于 REPO_ROOT/release/。在本地创建签名标签后执行此操作。如果此操作顺利完成，将发布提交（而不是标签，参见上面的部分）推送到 scipy 仓库。

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

cibuildwheel 基础设施会从构建的轮子中运行测试，如果通过，则将轮子上传到 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, wheels)

  • GitHub Releases (sdist, 发布说明，变更日志)

  • 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 创建发布并上传所有发布工件。在此阶段，适宜推送标签并将新发布（候选）与该标签关联。例如，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 访问文档服务器；如果您没有 SSH 访问权限，请联系 @pv（服务器管理员）、@tylerjereddy 或 @rgommers（可以上传）。

网站本身的源代码维护在 scipy/docs.scipy.org 中。在 index.rst 的发行版本表中添加新的 SciPy 版本。推送该提交，然后执行 make upload USERNAME=yourusername。这仅适用于正式发行版，不适用于候选发行版。

总结#

发送电子邮件到以下邮件列表，宣布发行版

  • scipy-dev

  • numpy-discussion

  • python-announce（不适用于 beta/rc 版本）

对于 beta 和 rc 版本，请在电子邮件中要求人们进行测试（运行 scipy 测试并针对其自身代码进行测试）并在 Github 或 scipy-dev 上报告问题。

在最终发行版完成后，将相关更改移植到发行说明、构建脚本、tools/authors.py 中的作者姓名映射以及仅在维护分支上进行的任何其他更改到主分支。

本页内容