SciPy Core开发人员指南¶

决策过程¶

SciPy有一个正式的治理模型，记录在 SciPy项目治理。下面的部分以非正式的方式记录了有关代码和提交权限的决策在实践中发生的情况。正式的治理模式是领先的，以下内容仅供参考。

代码¶

任何关于添加(或不添加)新特性、打破向后兼容性或对代码库进行其他重大更改的重大决定都应该在讨论之后在Scipy-dev邮件列表中做出(最好是完全一致的)。

任何重要的更改(其中琐碎意味着打字错误或一行维护提交)都必须通过Pull Request(PR)进入。它必须由另一个开发商进行审查。如果审查进行得不够快，并且PR迅速合并是很重要的，PR的提交人应该向邮件列表发送一条消息，说明他/她打算在时间X不审查该PR，原因是Y，除非有人在此之前对其进行审查。

应该测试更改和新添加的内容。未经测试的代码是损坏的代码。

提交权限¶

谁获得提交权利由本科学计划指导委员会决定；提交权利的变化将在scipy-dev邮件列表上宣布。

确定新功能¶

到目前为止，接受提议的新功能的一般决策规则是有条件的：

该方法可应用于许多领域并且“普遍认为”是有用的，
它切合子模块的主题，并且不需要大量的支持框架来操作。
该实现看起来是合理的并且在未来不太可能需要太多调整(例如，有限的预期维护负担)，
有人想把它捐出来，然后
有人想要复查一下。

最后一个标准通常是建议功能的症结所在。在彻底审查代码之前，不能合并代码，而且总是有大量的维护任务积压，这会占用审查者的时间。理想情况下，投稿人应该在开始工作之前安排一位具有合适领域专业知识的审查员。

虽然很难给出“普遍有用并普遍同意工作”的含义的硬性规定，但权衡以下几点可能会有所帮助：

该方法在实践中是否适用于不同的领域？需要多少特定领域的背景知识才能正确使用它？
请考虑模块中已有的代码。您添加的内容是否有遗漏？它是否解决了您期望模块能够解决的问题？它是否在很大程度上补充了现有功能？
考虑通常期望的类似方法/功能的等价类。其中，什么是原则上的最小集，以便在剩余的提供的功能中不会有明显的遗漏？那会有多少东西呢？包括其中一个有代表性的用例是否涵盖大多数用例？从原则上讲，将最小集合中的所有内容都包含在模块中听起来合理吗？
您要添加的是文献中已经很好理解的内容吗？如果不是，你有多大把握会有好结果呢？与其他类似的方法相比，该方法执行得好吗？
请注意，一年两次的发布周期和向后兼容策略使得以后更难进行更正。

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

GitHub的开发¶

SciPy开发很大程度上是在GitHub上进行的；本节描述了处理问题、拉取请求和管理主要 scipy 存储库。

标签和里程碑¶

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

easy-fix ：适用于适合新贡献者解决的问题。
needs-work ：适用于具有尚未解决的审核注释的拉取请求。
needs-decision ：对于需要做出决定的问题或拉取请求。
needs-champion ：用于未由原作者完成但值得复活的拉取请求。
backport-candidate ：发布经理应该考虑进行后向移植的错误修复。

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

拉式请求审核工作流¶

审核拉式请求时，请使用拉式请求工作流功能，请参阅使用工作流功能。

处理拉取请求¶

在合并贡献时，提交者负责确保这些贡献满足 Contributing to SciPy 。还要检查scipy-dev邮件列表中是否讨论了新特性和向后兼容性中断。
新代码通过拉入请求(PR)进入。
将新代码与绿色按钮合并。在合并冲突的情况下，要求PR提交者改变基准(这可能需要提供一些git指令)。
完成PR的后端口和琐碎的添加(非常琐碎，比如打字错误或PEP8修复)可以直接推送。
对于添加了新功能或在某种程度上复杂的PR，在合并之前至少要等待一到两天。这样，其他人就有机会在代码进入之前发表评论。
挤压提交或清理您认为过于杂乱的PR的提交消息是可以的。不过，在执行此操作时，请确保保留原始作者姓名。
确保正确设置合并请购单上的标签和里程碑。
当您想要拒绝PR时：如果很明显，您可以直接关闭它并解释原因，如果不明显，那么最好先解释为什么您认为PR不适合包含在本网站上，然后让第二个提交者进行评论或关闭。

回溯¶

所有拉取请求(无论它们是否包含增强功能、错误修复或其他内容)都应该针对master发出。只有错误修复才适合回传到维护分支。本网站的后端策略是(A)仅修复重要的后端修复，以及(B)仅在合理确定将在相关维护分支上发布新的错误修复版本时才进行后端修复。通常，合并重要错误修复的开发人员会添加 backport-candidate 标记并ping发布经理，该经理决定是否以及何时完成后端口。后端口完成后， backport-candidate 标签必须再次去掉。

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

发行说明¶

当PR合并时，请考虑是否需要在发行说明中提及这些更改。值得一提的是：新特性、向后不兼容的更改、弃用和“其他更改”(任何其他值得注意的更改，请参阅旧版本说明以了解值得一提的内容)。

发行说明条目在维基上维护(例如https://github.com/scipy/scipy/wiki/Release-note-entries-for-SciPy-1.2.0).发布经理将从那里收集内容并将其集成到HTML文档中。我们使用这种机制来避免合并冲突，如果每个PR都接触到下面的同一文件 doc/release/ 直接去吧。

可以监视更改 (Atom feed )和拉出(维基是git回购： https://github.com/scipy/scipy.wiki.git )。

其他¶

PR状态页面： 当新的提交被添加到拉取请求中时，GitHub不会发出任何通知。这个 needs-work 然而，标签可能不再是正当的。 This page 概述已更新、需要审查、需要做出决定等的请购单。

Cross-referencing: 交叉引用GitHub上的问题和拉取请求通常很有用。GitHub允许通过使用 gh-xxxx 或 #xxxx 使用 xxxx 问题/请购单编号。这个 gh-xxxx 格式是强烈首选的，因为很明显这是一个GitHub链接。较旧的问题包含 #xxxx 这是关于Trac(我们在GitHub之前使用的)门票的。

PR命名约定： 拉入请求、问题和提交消息通常以三个字母的缩写开头，例如 ENH: 或 BUG: 。这对于快速查看提交/PR/问题的性质很有用。有关缩写的完整列表，请参见 writing the commit message 。

许可¶

SciPy在 modified (3-clause) BSD license 。贡献者添加到本许可证中的所有代码、文档和其他文件均按照本许可证授权，除非源代码中明确指定另一个许可证。贡献者保留他们编写的代码的版权，并提交给本网站以供收录。

与本网站使用的修改后的BSD许可证兼容的其他许可证是2条款BSD、MIT和PSF。不兼容的许可是需要归属/引用或禁止用于商业目的的GPL、Apache和自定义许可。

提交PRS时，通常会复制或派生内容，这些内容来自未经许可的代码或来自与本网站的许可不兼容的默认许可的代码。例如，StackOverflow上发布的代码受CC-by-SA许可证保护，由于类似共享条款，这是不兼容的。除非原始代码作者愿意在修改后的BSD(或兼容)许可下(重新)许可他/她的代码，否则这些贡献不能被接受纳入本网站。如果原始作者同意，请在源文件中添加注释，并将相关通信转发到scipy-dev邮件列表。

另一种常见的情况是从R、Octave(都是GPL许可的)或商业应用程序中的代码翻译或派生代码。这样的代码也不能包含在本网站中。使用与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版本字符串的示例包括：

16.0
15.1
14.0a1
14.0b2
14.0rc1
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中移除某些内容之前，应该这样做：

建议弃用scipy-dev邮件列表上的功能，并获得同意。
添加 DeprecationWarning 声明该功能已弃用，以及在哪个版本中。有关Cython API，请参见不推荐使用公共Cython API 对于实际的步骤。
在该版本的发行说明中提及不推荐使用的内容。
等待，直到引入的版本发布日期后至少6个月 DeprecationWarning 在删除该功能之前。
在发行说明中提到删除该功能。

实际上，6个月的等待期通常意味着等待两次释放。在引入警告时，还要确保在运行测试套件时过滤掉这些警告，这样它们就不会污染输出。

对于特定的弃用，可能有理由忽略此弃用策略；这可以在scipy-dev邮件列表中讨论。

分发¶

分发Python包并不是一件容易的事--特别是对于像SciPy这样具有复杂构建需求的包--并且可能会发生变化。有关推荐的工具和技术的最新概述，请参阅 Python Packaging User Guide 。本文讨论了本科学计划的一些主要问题和考虑因素。

依赖项¶

依赖项是用户为了使用(或构建/测试)包而必须安装的东西。它们通常会带来麻烦，特别是如果它们不是可选的。SciPy试图将其依赖项保持在最低限度；目前它们是：

Unconditional run-time dependencies:

Numpy

Conditional run-time dependencies:

pytest(运行测试套件)
asv (要运行基准测试，请执行以下操作)
matplotlib (对于某些可以生成绘图的函数)
Pillow (用于图像加载/保存)
scikits.umfpack (可选用于 sparse.linalg )
mpmath (有关更多扩展测试，请参阅 special )
pydata/稀疏(中的兼容性支持 scipy.sparse )

Unconditional build-time dependencies:

Numpy
BLAS和LAPACK实施(参考BLAS/LAPACK、ATLAS、OpenBLAS、MKL均可用)
Cython
setuptools
pybind11

Conditional build-time dependencies:

wheel (python setup.py bdist_wheel )
Sphinx (文档)
PyData Sphinx theme (文档)
Sphinx-Panels (文档)
matplotlib (文档)
LaTeX(pdf文档)
Pillow (文档)

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

当一个包提供了有用的功能，并且它被提议作为一个新的依赖项时，还要考虑它对供应商是否有意义(例如，将它的副本与Scipy一起发布)，而不是包。例如, decorator 是在美国销售的 scipy._lib 。

报告给的唯一依赖项 pip 是 Numpy, 看见 install_requires 在本网站的主要 setup.py 。SciPy不需要其他依赖项即可正常运行

有关依赖项处理的问题¶

Python打包工具处理项目报告的依赖项的方式存在一些问题。因为本网站定期收到关于这方面的错误报告，所以我们在这里详细介绍一下。

SciPy仅报告其对NumPy VIA的依赖 install_requires 如果系统上根本没有安装NumPy，或者在使用 bdist_wheel 。SciPy不再使用 setup_requires (它在过去调用了 easy_install )；构建依赖关系现在仅通过 pyproject.toml 。 pyproject.toml 依靠PEP517； pip 有 --no-use-pep517 和 --no-build-isolation 可能忽略的标志 pyproject.toml 或者以不同的方式对待-如果用户使用这些标志，他们自己负责安装正确的构建依赖项。

NumPy和其他依赖项的版本范围¶

对于依赖项，重要的是为它们的版本设置下限和上限。为 build-time 依赖项，它们在 pyproject.toml 而这些版本将会 only 应用于本网站的构建本身。可以为依赖项指定范围或特定版本，例如 wheel 或 setuptools 。对于NumPy，我们还必须担心ABI兼容性，因此我们使用 == 到支持的最低版本(因为NumPy的ABI是向后兼容的，但不是向前兼容的)。

为 run-time dependencies (目前仅限 numpy )，我们在中指定版本范围 pyproject.toml 以及在 install_requires 在……里面 setup.py 。获得右上界有点棘手。如果我们不设定任何界限，几年后就会推出一个太新的版本，到那时，NumPy可能已经弃用并删除了一些SciPy所依赖的API。另一方面，如果我们将上限设置为最新发布的版本，那么一旦新的NumPy版本发布，就不会有与之匹配的SciPy版本。考虑到NumPy和SciPy都以6个月为周期发布，并且NumPy中不推荐使用的特性应该在另外两个版本中保留，我们将上限指定为 <1.xx+3.0 (其中 xx 是最新发布的NumPy的次要版本。

支持的Python和NumPy版本¶

这个 Python 中的PyPI分类器列表中列出了SciPy支持的版本 setup.py ，并且在每个版本的发行说明中都有提及。将尽快支持所有新发布的Python版本。有关删除对Python或NumPy版本的支持的常规策略，请参阅 NEP 29 。取消支持的最终决定总是在scipy-dev邮件列表上做出。

支持的最低 Numpy 发行说明中提到了SciPy版本的版本，并将其编码为 pyproject.toml ， scipy/__init__.py 以及 install_requires 的字段 setup.py 。通常，最新的SciPy版本支持大约5-7个NumPy的次要版本：最多2.5年前的NumPy版本(考虑到撰写本文时NumPy发布的频率约为2倍/年)，外加未来的两个版本。

中记录了受支持的可选依赖项和编译器版本工具链路线图。请注意，并不是所有受支持的可选依赖项版本都经过了本网站的持续集成设置的良好测试，或者根本没有测试过。与此相关的问题会在问题跟踪器或邮件列表中出现时进行处理。

生成二进制安装程序¶

注解

本节仅介绍如何构建SciPy二进制安装程序以分发。有关在将要使用的计算机上构建SciPy的信息，请参见 this scipy.org page 。

在构建二进制文件并将其分发到PyPI或其他地方时，有许多事情需要考虑。

General

二进制文件特定于单个Python版本(因为不同的Python版本不兼容ABI，至少最高可达Python3.4)。
根据您需要支持的最低NumPy版本进行构建，那么它将适用于具有相同主版本号的所有NumPy版本(NumPy确实保持向后ABI兼容性)。

Windows

目前，为本网站构建与Python.org兼容的二进制文件最容易获得的工具链是安装MSVC(参见https://wiki.python.org/moin/WindowsCompilers)和mingw64-gfortran)。支持此配置需要来自NumPy>=1.14.dev的numpy.distutils和GCC/gfortran编译的静电 openblas.a 。此配置当前用于https://github.com/MacPython/scipy-wheels的Appveyor配置
对于使用免费工具链构建的64位Windows安装程序，请使用https://github.com/numpy/numpy/wiki/Mingw-static-toolchain.中记录的方法一旦明确工具链的维护是长期可持续的，这种方法很可能被用于本科学计划本身。请参阅 MingwPy 项目和 this thread 有关详细信息，请参阅。
生成64位Windows安装程序的另一种方式是使用 icc ， ifort 加号 MKL (或 MSVC 而不是 icc )。有关英特尔工具链的说明，请参阅 this article 有关(部分)MSVC说明，请参见 this wiki page 。
早期的SciPy版本包含一个.exe“超级软件包”安装程序。它们包含3个完整的构建(没有sse、sse2、sse3)，并且是使用https://github.com/numpy/numpy-vendor.构建的已知该构建设置已不能很好地工作，不再受支持。由于复杂的DLL分发问题，它使用G77而不是gfortran(请参见 gh-2829 )。由于工具链不再受支持，因此不再需要G77支持，并且本网站现在可以包含Fortran 90/95代码。

OS X

要生成支持各种Python版本(来自python.org、Homebrew、MacPython)的OS X控制盘，请使用https://github.com/MacPython/scipy-wheels.提供的构建方法
OS X上python.org中的Python DMG安装程序仍可通过以下方式生成 tools/scipy-macosx-installer/ 。但是，由于在PyPI上有了二进制轮子，SciPy不再分发这些安装程序。

Linux

PyPI兼容的Linux轮子可以通过 manylinux 项目。在https://github.com/MacPython/scipy-wheels.中设置了用于本网站的TravisCI的相应构建设置

其他Linux构建设置会导致PyPI不兼容的轮子，这些轮子需要通过自定义通道分发，例如在 Wheelhouse, 请参阅 wheel 和 Wheelhouse 医生。

发布SciPy版本¶

在最高级别，这是发布经理发布新的SciPy版本时所做的工作：

在scipy-dev邮件列表上提出一个发布时间表。
创建版本的维护分支。
标记版本。
构建所有发布构件(源代码、安装程序、文档)。
上载版本工件。
宣布发布。
将相关更改移植到发行说明，并将构建脚本移植到Master。

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

回溯
标签和里程碑
版本编号
支持的Python和NumPy版本
不推荐使用

建议发布时间表¶

典型的发布周期如下所示：

创建维护分支
发布测试版
发布“发布候选版本”(RC)
如果需要，发布一个或多个新的RC
一旦最后一个候选版本没有问题，就发布最终版本

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

理想情况下，最终版本与上一版RC完全相同，但是可能会有一些细微的差异--这取决于发布经理来判断其风险。通常，如果编译后的代码或复杂的纯Python代码发生更改，则需要新的RC，而从MASTER向后移植的简单错误修复不需要新的RC。

要提出时间表，请将包含分支和Beta/RC/最终版本的预计日期的列表发送到scipy-dev。在同一封电子邮件中，请每个人检查是否有重要的问题/公关需要包括在内，并且没有标记为发布的里程碑或“Backport-Candidate”标签。

创建维护分支¶

在分支之前，请确保尽可能更新发行说明。包括以下内容的输出 tools/gh_lists.py 和 tools/authors.py 在发行说明中。

维护分支机构被命名为 maintenance/<major>.<minor>.x (例如0.19.x)。要创建一个分支，只需将具有正确名称的分支推送到scipy repo即可。在此之后，立即按下提交，其中您将递增主分支上的版本号，并为该新版本添加发行说明。向scipy-dev发送一封电子邮件，让人们知道您已经这样做了。

更新依赖项的上限¶

在MASTER中，我们不设置上限，因为我们希望在那里测试依赖项的新版本或开发版本。然而，在维护分支中，目标是能够创建持续工作数年的版本。因此，必须设置正确的上限。创建维护分支机构后，必须更新以下位置：

pyproject.toml ：所有构建时依赖项，以及支持的Python
和NumPy版本
setup.py ：支持的Python和NumPy版本
scipy/__init__.py ：对于NumPy版本检查

每个文件都有说明如何设置正确上限的注释。

标记版本¶

首先，确保您已正确设置了GPG。有关签署版本标签的讨论，请参阅https://github.com/scipy/scipy/issues/4919，如果您没有gpg密钥，请参阅https://keyring.debian.org/creating-key.html获取有关创建gpg密钥的说明。请注意，在某些平台上，它可能更适合使用 gpg2 而不是 gpg 以便可以通过以下方式存储密码 gpg-agent 如https://github.com/scipy/scipy/issues/10189.中所讨论的远程准备版本时，可能需要设置 pinentry-mode loopback 在……里面 ~/.gnupg/gpg-agent.conf 因为使用 gpg2 否则将通过无法访问的图形密码提示继续。

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

gpg --send-keys <yourkeyid>

检查所有相关的提交是否都在分支中。特别是，检查发布里程碑下的问题和PR(标记为“Backport-Candidate”的https://github.com/scipy/scipy/milestones)，PR)，并且版本说明是最新的并且包含在HTML文档中。

然后编辑 setup.py 要获取正确的版本号(设置 ISRELEASED = True )，并使用如下消息提交它 REL: set version to <version-number> 。先不要把这个承诺推给本网站回购。

最后，使用以下命令在本地标记发行版 git tag -s <v1.x.y> ( -s 确保标签已签名)。如果 gpg2 是首选的，那么 git config --global gpg.program gpg2 可能是合适的。继续构建发布工件(下一节)。只有在您成功构建了sdist和docs之后，才会将版本提交给scipy repo。然后继续制造轮子。只有在TravisCI和Appveyor上的所有轮子都成功构建之后，才能将发布标签推到回收站(如果失败，您必须以其他方式移动标签-这是不好的做法)。最后，在推送标记之后，还要推送第二次提交，该提交会递增版本号并设置 ISRELEASED 再犯一次错。这也适用于新的候选版本，并用于删除 rc 从候选版本切换到合适的版本时添加。

生成版本工件¶

以下是为版本创建的工件的完整列表：

源档案 (.tar.gz ， .zip 和 .tar.xz 仅适用于GitHub版本 .tar.gz 已上载到PyPI)
适用于Windows、Linx和OS X的双轮
文档 (html ， pdf )
A README 文件
A Changelog 文件

源存档、ChangeLog和自述文件是通过运行以下命令构建的 paver release 在repo根目录中，并最终在 REPO_ROOT/release/ 。在本地创建签名标记后执行此操作。 paver release 将对构建环境中可用的Cython版本敏感，因此请确保您的版本符合发行版的最低要求。如果此操作完成时没有问题，请将发布提交(而不是标签，请参见上面的部分)推送到scipy repo。如果 pavement.py 正在引起问题，也可以简单地使用 python setup.py sdist 并从执行发行说明任务 pavement.py 用手写的。

要构建轮子，请在https://github.com/MacPython/scipy-wheels上将提交推送到用于当前版本的分支。这将触发TravisCI上所有需要的Python版本的构建。更新并检查 .travis.yml 和 appveyor.yml 提交构建的配置文件，以及用于构建的Python和NumPy(它需要是每个Python版本支持的最低NumPy版本)。有关更多详细信息，请参阅Scipy-Wlowers资源库中的自述文件。请注意，因为可能需要几个月的时间 SciPy 版本时，有时需要更新的版本 gfortran-install 和 multibuild 用于轮子构建的子模块。如果轮子构建显示需要使用维护分支上的后端口修复的问题，则可以移除本地标记(例如 git tag -d v1.2.0rc1 )，并在新的候选提交上重新开始上面的标记。

TravisCI和Appveyor构建从构建的轮子运行测试，如果通过，则将轮子上载到指向https://github.com/MacPython/scipy-wheels的容器一旦成功构建轮子，建议在中创建版本化分支 scipy-wheels repo，例如，如果有多个候选版本，它将被调整为指向不同的维护分支提交。

从那里，您可以下载它们以上传到PyPI。这可以使用以下命令以自动方式完成 tools/download-wheels.py ：：

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

要使用的正确网址显示在https://github.com/MacPython/scipy-wheels中，并且应该与上面的地址一致。

在此之后，我们希望重新生成自述文件，以便在其中包含刚刚下载的车轮的MD5和SHA256校验和。运行：：

$ paver write_release_and_log

上载版本工件¶

对于一个版本，目前网络上有五个地方可以上传内容：

PyPI(焦油球、轮子)
GitHub版本(tarball、发行说明、ChangeLog)
scipy.org(发布公告)
docs.scipy.org(html/pdf docs)

PyPI：

首先上传轮子，然后上传sdist：：

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

如果 gpg2 是优选的，则上述命令还可以包括 --sign-with gpg2

GitHub发布：

在https://github.com/scipy/scipy/releases上使用图形用户界面创建版本并上传所有版本工件。在此阶段，推送标记并在GUI中将新版本(候选)与此标记相关联是合适的。例如, git push upstream v1.2.0rc1 ，在哪里 upstream 表示 scipy/scipy 。检查以前的版本以准确确定哪些工件应该包含在GUI上载过程中是很有用的。此外，请注意，版本说明不会自动填充到GitHub上的版本描述中，一些手动重新格式化到标记可能会非常有帮助，以匹配网站上以前版本的格式。我们通常不在这些GUI描述中包括问题和拉入请求列表。

scipy.org：

该站点的来源在https://github.com/scipy/scipy.org.中更新中的新闻部分 www/index.rst 然后再做 make upload USERNAME=yourusername 。这只适用于适当的版本，不适用于候选版本。

docs.scipy.org：

首先，通过运行以下命令构建scipy文档 make dist 在……里面 scipy/doc/ 。验证它们看起来是否正常，然后使用以下命令将它们上载到文档服务器 make upload USERNAME=rgommers RELEASE=0.19.0 。请注意，需要通过SSH访问文档服务器；如果没有，请询问@pv(服务器管理员)或@rgommers(可以上传)。

网站本身的源代码在https://github.com/scipy/docs.scipy.org/.中维护将新的SciPy版本添加到的版本表中 index.rst 。按下提交，然后执行 make upload USERNAME=yourusername 。这只适用于适当的版本，不适用于候选版本。

结束工作¶

向以下邮件列表发送电子邮件宣布发布：

scipy-dev
麻木的讨论
Python-公告(不适用于测试版/RC版)

对于测试版和RC版，请要求电子邮件中的人员测试(运行scipy测试并针对他们自己的代码进行测试)，并报告有关Github或scipy-dev的问题。

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

工具链路线图

SciPy API开发指南