Numba 发布流程

从宏观角度来看，Numba 发布流程的目标是发布与给定版本号对应的源代码和二进制工件。这通常涉及一系列必须按正确顺序勤勉执行的单独任务。Numba 和 llvmlite 通常同步发布，因为 Numba 版本与相应的 llvmlite 版本之间通常存在一对一的映射关系。

本节包含各种说明和模板，可用于在 Numba GitHub 问题追踪器上创建 Numba 发布清单。这是发布过程中对维护者的一种辅助，有助于确保所有任务都按正确顺序完成，并且没有任务被意外遗漏。

如果在发布过程中出现新的或额外的项，请务必将其添加到清单模板中。另请注意，发布流程本身一直在不断完善中。这意味着此处的一些信息可能已过时。如果您发现此情况，请务必提交拉取请求以更新本文档。

所有发布清单均作为 GitHub 问题模板提供。要创建新的发布清单，只需打开一个新问题并选择正确的模板即可。

主发布候选版清单

这适用于次要版本发布的首个/主要发布候选版，即每个系列的首个发布版。它很特殊，因为在此次发布中，必须创建发布分支。发布候选版的索引从 1 开始。

## Numba X.Y.Z

* [ ] Merge to main.
    - [ ] "remaining Pull-Requests from milestone".
* [ ] Check Numba's version support table documentation. Update via PR if
      needed.
* [ ] Review deprecation schedule and notices. Make PRs if need be.
* [ ] Create changelog using instructions at: docs/source/developer/release.rst
* [ ] Merge change log changes.
    - [ ] "PR with changelog entries".
* [ ] Create X.Y release branch.
* [ ] Create PR against the release branch to make `numba/testing/main.py`
      to refer to `origin/releaseX.Y` instead of `origin/main`.
* [ ] Dependency version pinning on release branch
  * [ ] Pin llvmlite to `0.A.*`.
  * [ ] Pin NumPy if needed
  * [ ] Pin TBB if needed
* [ ] Run the HEAD of the release branch through the build farm and confirm:
  * [ ] Build farm CPU testing has passed.
  * [ ] Build farm CUDA testing has passed.
  * [ ] Build farm wheel testing has passed.
* [ ] Annotated tag `X.Y.Zrc1` on release branch (no `v` prefix).
* [ ] Build and upload conda packages on buildfarm (check "upload").
* [ ] Build wheels and sdist on the buildfarm (check "upload").
* [ ] Verify packages uploaded to Anaconda Cloud and move to `numba/label/main`.
* [ ] Upload wheels and sdist to PyPI (upload from `ci_artifacts`).
* [ ] Verify wheels for all platforms arrived on PyPi.
* [ ] Initialize and verify ReadTheDocs build.
* [ ] Post announcement to discourse group and ping the release testers group
  using `@RC_Testers`.
* [ ] Post link to X and to Mastodon and...

### Post Release:

* [ ] Clean up `ci_artifacts` by moving files to sub-directories
* [ ] Tag `X.Y+1.0dev0` to start new development cycle on `main`.
* [ ] Update llvmlite dependency via PR to `main`, PR includes version updates
      to:
  * [ ] `setup.py`
  * [ ] `numba/__init__.py`
  * [ ] `docs/environment.yml`
  * [ ] `buildscripts/incremental/setup_conda_environment.sh`
  * [ ] `buildscripts/incremental/setup_conda_environment.cmd`
  * [ ] `buildscripts/condarecipe.local/meta.yaml`
* [ ] Update release checklist template with any additional bullet points that
      may have arisen during the release.
* [ ] Close milestone (and then close this release issue).

打开主发布清单.

后续发布候选版、最终发布版和补丁发布版

一个系列中后续的发布通常涉及一系列的 cherry-pick 操作，因此其操作步骤略有不同。

## numba X.Y.Z

* [ ] Cherry-pick items from the X.Y.Z milestone into a cherry-pick PR.
* [ ] Update the "version support table" in the documentation with the final
  release date (FINAL ONLY) and add to cherry-pick PR
* [ ] Update `CHANGE_LOG` on cherry-pick PR
* [ ] Check if any dependency pinnings need an update (e.g. NumPy)
* [ ] Approve cherry-pick PR
* [ ] Merge cherry-pick PR to X.Y release branch.
  * [ ] https://github.com/numba/numba/pull/XXXX
* [ ] Review, merge and check execution of release notebook. (FINAL ONLY)
* [ ] Run the HEAD of the release branch through the build farm and confirm:
  * [ ] Build farm CPU testing has passed.
  * [ ] Build farm CUDA testing has passed
  * [ ] Build farm wheel testing has passed
* [ ] Annotated tag X.Y.Z on release branch (no `v` prefix).
  `git tag -am "Version X.Y.Z" X.Y.Z`
* [ ] Build and upload conda packages on buildfarm (check `upload`).
* [ ] Build wheels and sdist on the buildfarm (check "upload").
* [ ] Verify packages uploaded to Anaconda Cloud and move to
  `numba/label/main`.
* [ ] Upload wheels and sdist to PyPI (upload from `ci_artifacts`).
* [ ] Verify wheels for all platforms arrived on PyPi.
* [ ] Verify ReadTheDocs build.
* [ ] Create a release on Github at https://github.com/numba/numba/releases (FINAL ONLY).
* [ ] Post link to X and to Mastodon and...
* [ ] Post announcement to discourse group and ping the release testers group
  using `@RC_Testers` (RC ONLY).
* [ ] Post link to python-announce-list@python.org.

### Post release

* [ ] Cherry-pick change-log and version support table modifications to `main`
* [ ] Snapshot Build Farm config
* [ ] Clean up `ci_artifacts` by moving files to subdirectories
* [ ] Update release checklist template with any additional bullet points that
      may have arisen during the release.
* [ ] Ping Anaconda Distro team to trigger a build for `defaults` (FINAL ONLY).
* [ ] Close milestone (and then close this release issue).

打开后续发布清单.

生成发布说明

Numba 发布说明由两部分组成，需要调用两个工具。

发布摘要和值得注意的项概览：使用 towncrier
拉取请求和作者列表：使用 maint/gitlog2changelog.py

使用 `towncrier`

在每次发布之前，使用 Towncrier 生成更新日志。这将收集所有新闻片段，将它们组合起来，并将结果输出到单个更新日志文件。在创建更新日志期间，系统会询问用户是否删除现有新闻片段。在生成发布说明的情况下，应删除它们，以避免它们在发布后的更新日志创建中被意外包含。

towncrier build –version=0.xx.x

使用 `maint/gitlog2changelog.py`

脚本 maint/gitlog2changelog.py 用于生成拉取请求和作者的列表。要准备使用它

安装依赖项：conda install docopt pygithub gitpython。
在 GitHub 上生成一个细粒度的个人访问令牌（Personal Access Token），并赋予公共仓库的读取权限。这可以在 GitHub 个人访问令牌设置中完成。
确定更新日志的基础提交。这里有两种已知方法
- 使用 git 查找基础提交。这是 main 和最后一个发布分支之间的共同提交，可以通过运行 git merge-base main <branch> 来确定。例如，如果正在为 0.59 版本生成发布说明，branch 可能是 release0.58。
- 使用该发布的开发提交。例如，对于 0.59.0rc1 发布，这将是 0.59.0dev0。

然后可以在仓库根目录中调用该脚本，命令如下

python maint/gitlog2changelog.py --token="<token>" --beginning="<base commit>" \
                                 --repo="numba/numba" --digits=4

这会使用上面确定的令牌和提交。--digits 参数指定拉取请求号的位数——目前是 4 位，但在本文撰写后不久将变为 5 位——届时，需要运行两次脚本，一次使用 --digits=4，另一次使用 --digits=5，然后合并结果。

该脚本应以可粘贴到仓库根目录下的 CHANGE_LOG 文件顶部的形式输出发布说明。截断的示例输出如下所示

Pull-Requests:

* PR `#8990 <https://github.com/numba/numba/pull/8990>`_: Removed extra block copying in InlineWorker (`kc611 <https://github.com/kc611>`_)
* PR `#9048 <https://github.com/numba/numba/pull/9048>`_: Dynamically allocate parfor schedule. (`DrTodd13 <https://github.com/DrTodd13>`_)

<... some output omitted ...>

Authors:

* `apmasell <https://github.com/apmasell>`_
* `DrTodd13 <https://github.com/DrTodd13>`_

<... some output omitted ...>

请注意，列表可能包含重复项，因此您需要手动检查并消除这些重复项！重复项通常是拉取请求提交到 main 分支后，又被 cherry-pick 到 release 分支所致。当为发布候选版修复问题或将已解决的问题回溯移植到补丁发布版时，可能会发生这种情况。

另请注意，在更新日志的拉取请求被打开后，您必须手动添加它。这必须在拉取请求本身打开之后进行，因为在此之前拉取请求的链接和编号是不存在的。