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提交者进行变基（这可能需要提供一些 git 指令）。

  • 为了完成一个PR（真的非常简单，比如拼写错误或PEP8修复），可以推送回溯和微小的添加。

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

  • 如果你认为某个PR的提交记录或提交信息过于混乱，可以对其进行压缩或清理。但在进行此操作时，请确保保留原始作者的姓名。每当提交信息不符合 编写提交信息 中的指南时，强烈建议进行压缩。

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

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

回溯移植#

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

一个好的回溯拉取请求策略是将多个主分支拉取请求合并，以减轻持续集成测试的负担，并减少维护分支历史中的合并提交混乱。通常最好为回溯拉取请求中的每个主分支拉取请求保留一个单独的提交。这样，历史记录清晰，如果需要，可以简单地还原。

发行说明#

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

发布说明条目维护在 维基 上。发布管理员将从那里收集内容并将其整合到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 以及要求署名/引用或禁止用于商业目的的自定义许可证。

PRs 经常提交的内容是从未授权的代码或与 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 论坛上讨论。

Vendored Code#

SciPy 代码库的许多部分在其他地方维护，并在 SciPy 中作为外部库引入。其中一些部分作为 git 子模块引入，例如 boost_math。

其他部分并未作为 git 子模块进行分发，尽管它们有维护的上游。这主要是出于历史原因，未来这些部分可能会看到上游贡献的补丁，并成为 git 子模块。

维护者应小心 不要 接受贡献（尤其是微小的更改）到 SciPy 中代码正在上游积极维护的部分。相反，他们应引导贡献者到上游仓库。目前，这包括代码库的以下部分：

  • 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 构建轮子时，才通过 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 的信息，请参阅 此 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 构建的。该构建设置已知不再有效，并且不再受支持。由于复杂的 DLL 分发问题（参见 gh-2829），它使用了 g77 而不是 gfortran。由于工具链不再受支持，g77 支持不再需要，SciPy 现在可以包含 Fortran 90/95 代码。

Linux

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

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

制作 SciPy 版本#

在最高层面上，这是发布经理在发布新 SciPy 版本时所做的事情：

  1. 在 SciPy 论坛 https://discuss.scientific-python.org/ 上提出一个发布时间表。

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

  3. 标记发布。

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

  5. 上传发布工件。

  6. 宣布发布。

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

在本指南中，我们试图详细描述如何执行上述每个步骤。除了这些必须由发布经理执行的步骤外，以下是与发布相关的活动和惯例的描述：

  • 回溯移植

  • 标签和里程碑

  • 版本编号

  • 支持的Python和NumPy版本

  • 弃用

提议发布时间表#

一个典型的发布周期如下：

  • 创建维护分支

  • 发布一个测试版

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

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

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

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

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

要提议一个时间表，请发送一份包含分支和测试版/候选版/最终版发布日期的列表到 SciPy 论坛 https://discuss.scientific-python.org/。在同一消息中，请所有人检查是否有重要的问题/PR需要包含在内，但尚未标记为发布里程碑或“回溯候选”标签。

创建维护分支#

在分支之前，确保尽可能更新发布说明。在发布说明中包含 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密钥，创建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: 设置版本为 <version-number> 的消息提交这些更改。暂时不要将此提交推送到 SciPy 仓库。

最后，在本地用 git tag -s <v1.x.y> 标记发布（-s 确保标签被签名）。如果偏好使用 gpg2，那么 git config --global gpg.program gpg2 可能是合适的。继续构建发布工件（下一节）。只有在成功构建了源代码包和文档后，才能将发布提交推送到 scipy 仓库。然后继续构建轮子。只有在 TravisCI 和 Appveyor 上成功构建了所有轮子后，才能将发布标签推送到仓库（如果失败，你必须移动标签，这是不好的做法）。最后，在推送标签后，还要推送第二个提交，该提交增加版本号并附加 .dev0 给 version:，并将 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 版本和平台构建。在分支之后，应立即在 pyproject.toml 中更新 NumPy 和其他依赖项的适当版本固定。如果轮子构建揭示了需要在维护分支上通过回传修复的问题，您可以删除本地标签（例如 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 文件，以便在其中包含刚刚下载的轮子的 MD5 和 SHA256 校验和。再次运行 python dev.py notes。

上传发布工件#

对于一个发布版本，目前有五个网站可以上传内容：

  • PyPI (源代码分发包, 轮子)

  • GitHub 发布 (源代码分发包, 发布说明, 变更日志)

  • scipy.org (发布公告)

  • docs.scipy.org (html 文档)

PyPI:

首先上传轮子，然后上传源代码分发包:

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 描述中的问题和拉取请求列表。

scipy.org:

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

docs.scipy.org:

首先在 scipy/doc/ 目录下运行 make dist 来构建 scipy 文档。验证它们看起来是否正常，然后使用 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 中的作者名称映射以及仅在维护分支上进行的任何其他更改到主分支。

On this page