ONNX 发布¶
ONNX 项目未来计划大约每四个月发布一次。我们遵循 Semver 版本控制方法，并将在每次发布时由社区决定进行主版本更新还是次版本更新。
准备工作¶
联系 SIG Arch/Infra 负责人，确认发布分支所需的检查项是否仍然有效且已更新，以及是否存在依赖已过时的硬编码的运行器镜像版本，这些可能需要更新。检查发布分支的“必需检查项”是否仍然是最新的或需要调整：“Branches” -> “Branch protection rules”。
确定新版本的版本号（X.Y.Z）
在 Slack 频道 Releases（https://lfaifoundation.slack.com/archives/C018VGGJUGK）中讨论
对于 (v.X.Y.Z)，如果发布版本为 1.16.0，则
X=1, Y=16, Z=0
新分支将是
rel-1.16.0分支保护规则会自动应用于符合此格式的分支。
新标签将是
v1.16.0
在 发布后勤维基 中为新版本创建页面
在创建发布分支之前，强烈建议您提前准备好**初步的发布说明**——最好保存在共享位置，例如**发布维基页面**。这些说明应包含**新功能**的清晰摘要、**错误修复**列表、任何**已知问题**，以及特别是任何**弃用或移除项**，并附上相关工单或文档的链接。准备好这些信息可确保团队在分支创建后立即自信且迅速地创建
rc1（发布候选 1），而无需延迟。在此阶段迅速行动也有助于**减少在主分支和发布分支上进行并行工作**的需求，从而最大程度地减少合并冲突、重复工作和协调开销。此做法支持更顺畅、更透明的发布流程。为了生成良好的发布说明，如果拉取请求的名称有意义且具有相应的标签，那将很有帮助。标签也可以追溯性地添加到已经合并的拉取请求中。
使用的标签可以在 此处 找到
在 GitHub 上起草发布时获得的初步发布说明。
创建发布分支¶
在 `main` 分支中，创建发布分支之前
在 version.h 中增加 `LAST_RELEASE_VERSION`。
设置为 X.Y.Z，这与您当前正在创建的发布分支相同。
在发布分支创建后，`main` 分支中的 `VERSION_NUMBER` 将被增加到下一个未来版本。
在 ONNX proto 文件、Versioning.md、schema.h、helper.py 和 helper_test.py 中，确保新发布的发布版本、IR 版本、ai.onnx opset 版本、ai.onnx.ml opset 版本和 ai.onnx.training opset 版本是正确的。
创建发布分支
在 branches 中点击“New branch”，选择 `main` 作为 Source。
确保新分支上的所有测试都通过。
创建发布分支后
创建 PR 以将 `main` 分支中的 `VERSION_NUMBER` 文件设置为下一个未来版本，即 `X.Y+1.0`。
创建 PR 以将新发布分支中的 `VERSION_NUMBER` 文件设置为 `X.Y.Zrc1`。
例如，1.16.0 的第一个发布候选版本将是 `1.16.0rc1`。
在 `onnx/defs/operator_sets.h` 和 `onnx/defs/schema.h` 中增加 ai.onnx 域的 opset 版本，以便将来添加和修改运算符时使用。
例如，这个 演示 PR。
将发布候选版本上传到 TestPyPI（无需离线步骤，从 onnx 版本 1.19 开始）¶
转到“Actions” -> 选择 “Create Releases” -> 点击“Run workflow”按钮，并使用以下配置：
RC-Candidates
Build-mode: Release
此按钮将触发不同操作系统的构建。
所有单个运行的工件都可以在对应的作业中找到。
在最终合并之前，必须通过设置的部署环境手动确认。
将发布候选版本上传到 TestPyPI（适用于截至 1.18（含）的版本 / 1.19 的后备方案）¶
重要提示
**等待** PR 合并并构建以设置发布分支的 `VERSION_NUMBER`，然后再继续。
如果您尚未安装 `twine`，请安装：`pip install twine`
当 `twine` 命令提示输入密码时，请使用 API 令牌。您的密码将不起作用。
注意：TestPyPI 和 PyPI 是独立的账户，因此请确保您使用的账户与您上传到的位置相符。
与 PyPI 类似，发布版本只能上传到 TestPyPI **一次**。
要更新已上传的文件，您必须增加 `VERSION_NUMBER`，重新构建，并上传新的 X.Y.Zrc2 等。
要测试上传命令，您可以使用 docker 或 podman 创建本地 pypi 服务器。
启动服务器 `docker run --rm -it --platform linux/amd64 -p 80:8080 pypiserver/pypiserver:latest run -a . -P .`
这将启动一个本地 pypiserver，无需身份验证（任何用户/密码都可用）。
容器不保存状态。停止并重新启动它将允许您多次推送同一版本。
上传文件
wheels: `twine upload --repository-url http://127.0.0.1:80 --verbose -u fake -p fake *.whl`
source: `twine upload --repository-url http://127.0.0.1:80 --verbose -u fake -p fake dist/*`
从您的测试服务器拉取和安装
pip uninstall -y onnx && pip install --index-url http://127.0.0.1:80/simple/ --pre onnx
推送 Wheels
从 ONNX Github Actions 收集发布候选版本的 wheel 文件。
ONNX GitHub Action
找到发布分支的运行
或者通过点击“Run workflow”，选择发布分支，然后点击“Run Workflow”来启动一次运行。
点击已完成的运行，滚动到“Artifacts”部分（底部），然后点击“wheels”下载文件。
解压 wheels.zip 文件并将它们的内容合并到一个文件夹中。
手动将生成的 wheels 上传到 TestPyPI：`twine upload --repository testpypi --verbose -u
/*.whl`。 ONNX 项目的当前所有者之一需要授予您项目访问权限，您才能推送文件。
文件中构建的项目名称和版本。
Source Distribution
确保所有 git 子模块都已更新。
git submodule update --init
确保 git checkout 是干净的——
运行
git clean -nxd确保不存在以下自动生成的头文件。
onnx/onnx-operators.pb.cc
onnx/onnx-operator.pb.h
onnx/onnx.pb.cc
onnx/onnx.pb.h
如果存在，请运行
git clean -ixd并从您的本地分支中删除这些文件。
生成源分发文件：`python -m build --sdist`
如果您还没有 `build` 包，请运行 `pip install build`。
将源分发文件上传到 TestPyPI：`twine upload --repository testpypi --verbose -u
dist/*` 备注
ONNX 项目的当前所有者之一需要授予您项目访问权限，您才能推送文件。
文件中构建的项目名称和版本。
确认 TestPyPI 包可以安装
Wheel 安装：`pip uninstall -y onnx && pip install -i https://test.pypi.org/simple/ --pre onnx`
假设您的环境有预先构建好的 wheel，否则将开始源码安装。
源码安装：`pip uninstall -y onnx && pip install -i https://test.pypi.org/simple --no-binary onnx --pre onnx`
软件包验证¶
合作伙伴验证
用户应使用 _pip install –no-deps -i https://test.pypi.org/simple/ onnx_（并手动安装其依赖项，以免从 test-pypi 获取）来安装 rc-packages。
使用 onnxruntime 包进行测试
使用已安装的 onnxruntime 包运行 test_with_ort.py 中的测试脚本。
这些脚本使用 onnxruntime 函数（如 `InferenceSession` 和 `InferenceSession.run`）在特定的示例 ONNX 模型上测试 ONNX 函数，例如 `load`、`checker.check_model` 和 `shape_inference.infer_shapes`。
向外部仓库的开放问题
在转换器仓库中创建 GitHub issue，为它们提供软件包链接并测试发布版，然后再公开发布。
https://github.com/microsoft/onnxruntime
注意：他们的仓库中存在 How_To_Update_ONNX_Dev_Notes，其中记录了如何引入新的 ONNX 版本。
如果发现问题，应在 onnx `main` 分支中修复这些 bug，然后将其 cherry-pick 到发布分支。
跟进报告人，确保问题得到解决（并在新的 rc 中得到验证）或推迟到下一个版本。
正式发布¶
在此之前必须完成验证步骤！这是不可逆转的点。
发布后不应更改 git 标签。
一旦推送到 PyPI，就无法更新发布。必须进行新发布。
设置最终版本号¶
创建 PR 以从发布分支的 `VERSION_NUMBER` 文件中删除“rcX”后缀。
创建发布标签¶
根据发布分支起草发布。
在确定不再需要更改之前，请勿点击“Publish release”。
如果需要保存和稍后更新，请使用“Save Draft”。
发布将创建新的 git 标签。
Tag：请参见 准备工作 的顶部，了解要创建的标签。
Target：刚刚创建的发布分支。
Previous tag：选择上一个版本。
Write
使用 之前的发布 作为模板。
使用 Release logistics wiki 中的信息，该信息应在分支创建前创建。
添加自编写维基以来合并到发布中的任何其他提交。
.tar.gz 和 .zip 将在发布后自动生成。
上传到官方 PyPI¶
从 1.19 版本开始，最终发布也将通过 Github 的“Action” -> “Create releases”（见上文）推送到 pypi。使用以下配置进行正式发布：
注释：¶
软件包上传到 PyPI 后，**您无法在同一 PyPI 实例上覆盖它**。
**请确保 TestPyPI 上的一切都正常后再上传到 PyPI。**
PyPI 拥有与 TestPyPI 分开的登录、密码和 API 令牌，但过程相同。ONNX PyPI 所有者需要授予访问权限等。
旧注释（使用 twine）¶
按照上面“上传发布候选版本到 TestPyPI”中的**Wheels**和**Source Distribution**步骤进行，并做以下更改：
在您的 PyPI 账户（**API 令牌**部分）中，为上传 onnx wheel 创建一个名为 `onnx` 的新 API 令牌。
推送 wheels 和源后，删除创建的令牌。
上传时，从 twine 命令中删除 `--repository testpypi`。
验证上传时，从 pip 命令中删除 `-i https://test.pypi.org/simple/` 和 `--pre`。
PyPI 发布后¶
公告
Slack
在 `onnx-release` 和 `onnx-general` 频道发布。
通过电子邮件列表通知 ONNX 合作伙伴
ONNX News 发布
更新 news.json，请参见 示例 news.json PR。
更新 conda-forge 包，使用新的 ONNX 版本。
ONNX 的 Conda 构建通过 conda-forge/onnx-feedstock 进行，该项目为构建包并将其上传到 conda-forge 提供基础设施。
在发布版本在 https://github.com/onnx/onnx/releases 上可用几小时后，`regro-cf-autotick-bot` 将自动创建一个 PR。
如果自动 PR 构建失败
创建 conda-forge/onnx-feedstock 的个人 fork。
基于自动 PR 分支创建个人分支。
解决构建问题。
提交一个基于您分支的替换 PR。
如果未创建自动 PR，则需要手动提交 PR。
注意：使用发布版本的 tar.gz 文件（来自 https://github.com/onnx/onnx/releases）的 sha256 哈希值（`sha256sum onnx-X.Y.Z.tar.gz`）。
合并到 main 分支
检查发布分支的哪些更改也与 main 分支相关。
如果在发布分支中直接进行了紧急更改，则将发布分支合并回 main 分支。
如果所有合并到发布分支（在分支创建后）的 PR 都是从 main 分支 cherry-pick 的，那么合并 PR 将显示为空，则无需此步骤。
移除 PyPI 上旧的 onnx-weekly 包
从 PyPI 中移除刚刚发布的版本的 onnx-weekly 包，以节省空间。
步骤
-
这是与 onnx 发布不同的项目，您可能需要从所有者那里请求访问权限。
点击目标软件包 -> Options -> Delete。
-
移除 PyPI 上旧的 release-candidate 包
从 PyPI 中移除 `onnx-release-candidate` 包，至少追溯到上一个发布版本指定的时间，以节省空间。
步骤
-
这是与 onnx 发布不同的项目，您可能需要从所有者那里请求访问权限。
点击目标软件包 -> Options -> Delete。
-