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 等）。根据情况，可能会添加其他标签

  • good-first-issue：适用于新贡献者处理的问题。

  • needs-work：适用于有未解决的审阅意见的拉取请求。

  • needs-decision：适用于需要决定的问题或拉取请求。

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

  • backport-candidate：发行经理应考虑向后移植的错误修复。

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

拉取请求审查工作流程#

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

处理拉取请求#

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

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

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

  • 向后移植和对 PR 进行微不足道的添加以完成 PR（真的微不足道，例如错别字或 PEP8 修复）可以直接推送。

  • 对于添加新功能或在某些方面比较复杂的 PR，请等待至少一两天后再合并。这样，其他人可以在代码进入之前有机会发表评论。

  • 压缩提交或清理你认为过于混乱的 PR 的提交消息是可以的。但请确保在执行此操作时保留原始作者姓名。如果提交消息没有（大致）遵循 编写提交消息 中的准则，强烈建议进行压缩。

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

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

向后移植#

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

向后移植拉取请求的一个好策略是合并几个主分支拉取请求，以减少持续集成测试的负担并减少维护分支历史的合并提交混乱。通常，最好为向后移植拉取请求中表示的每个主分支拉取请求使用单个提交。这样，历史记录清晰，并且可以在需要时以直接的方式还原。

发行说明#

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

发行说明条目维护在 wiki 上。发行经理将从那里收集内容并将其集成到 html 文档中。我们使用此机制来避免如果每个 PR 都直接触及 doc/release/ 下的同一文件时会发生的合并冲突。

可以监视更改（Atom 源）和拉取（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 打包用户指南。本文档讨论了 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 次）加上未来的两个版本。

可选依赖项和编译器的支持版本记录在 工具链路线图中。请注意，并非所有支持的可选依赖项版本都经过 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 构建的。已知该构建设置不再正常工作，并且不再受支持。它由于复杂的 DLL 分发问题而使用 g77 而不是 gfortran（请参阅 gh-2829）。由于该工具链不再受支持，因此不再需要 g77 支持，并且 SciPy 现在可以包含 Fortran 90/95 代码。

Linux

  • 可以通过 manylinux 项目生成与 PyPI 兼容的 Linux 轮子，该项目在我们的 cibuildwheel 基础结构下使用。

其他 Linux 构建设置会导致与 PyPI 不兼容的轮子，这些轮子需要通过自定义通道分发，例如在 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/。在同一消息中，请大家检查是否有需要包含但未标记有版本里程碑或“backport-candidate”标签的重要问题/PR。

创建维护分支#

在分支之前，请确保尽可能更新发布说明。在发布说明中包含 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>

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

然后，更新 pyproject.toml 中的 version，并提交更改，提交信息类似于 REL: set version to <版本号>。暂时不要将此提交推送到 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 发布)

  • 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] 的提交推送到用于当前发布的的分支。这将触发所有需要的 Python 版本和平台的 cibuildwheel 构建。NumPy 和其他依赖项的适当版本固定应该已经在分支后立即在 pyproject.toml 中更新。如果 wheel 构建揭示了需要在维护分支上修复的反向移植问题，您可以删除本地标签（例如 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 发布 (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 发布

使用 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 中的“新闻”部分。这仅适用于正式发布版本，不适用于候选发布版本。

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: ".*"
在此页