企业官网建设流程全解析

• 人工智能
• 深度学习
• 机器学习

导读

本文基于 ONNX 仓库的 docs/ReleaseAdministration.md 编写，系统讲解 ONNX 项目在稳定版本发布之后，由Architecture & Infra SIG 管理员负责执行的 PyPI 包存储清理任务。这些任务属于特权维护操作，不在发布经理（Release Manager）的常规发布清单范围内。读者读完本文后，将掌握：为什么需要清理 PyPI 存储、onnx-weekly周更包与 TestPyPI 候选版本的删除前提与操作步骤、删除前必须核验的关键要素，以及如何与 RELEASE-MANAGEMENT.md、docs/OnnxReleases.md 中的完整发布流程衔接。

一、角色与职责边界：为什么需要专门的发布管理

1.1 发布流程中的两类职责

ONNX 的发布过程分为两条并行的职责线：

• 发布经理（Release Manager）：负责版本规划、创建rel-X.Y.Z分支、上传候选版本、协调合作伙伴验证、发布正式版本等全流程工作，详见 docs/OnnxReleases.md 与 RELEASE-MANAGEMENT.md。
• Architecture & Infra SIG 管理员：负责发布后的存储清理等特权维护任务。这些操作需要 PyPI 项目管理权限，因此独立于发布经理执行。

1.2 为什么清理存储是必要的

ONNX 项目维护多个 PyPI 包与索引实例：

其中onnx-weekly每周发布一次，长期积累会占用大量项目存储空间；TestPyPI 上的 RC 版本在正式版发布后也失去存在意义。及时清理过期发行版（distribution）是控制存储成本、保持索引整洁的常规操作。

从源码结构可以印证周更包与稳定包是相互独立又彼此兼容的发行渠道：onnx/init.py 在读取版本号时会优先查找onnx包，若未安装稳定版则回退到onnx-weekly，这保证了两个包可以共存而不互相污染，也解释了为何onnx-weekly需要单独管理其发布历史。

二、删除操作的总原则：不可逆与三要素核验

2.1 删除是不可逆操作

包删除一旦执行无法撤销。文档明确强调：在删除任何一个 distribution 之前，必须先核验以下三要素：

1. 项目（Project）：确认是onnx还是onnx-weekly，避免误删；
2. 版本（Version）：确认版本号与目标发行版一致；
3. 包类型与目标索引（Package type and target package index）：确认是 wheel、sdist 等具体文件类型，以及位于 PyPI 还是 TestPyPI。

2.2 与 SIG 协调

任何清理操作都应与Architecture & Infra SIG提前协调，确认清理时机与范围，不要单独擅自执行。

三、清理场景一：Weekly 周更包（onnx-weekly）

3.1 清理时机与对象

稳定版本发布之后，管理员可以删除onnx-weekly中与该稳定版本号相同的 distribution。原因是：该版本已经以正式包形式进入 PyPI，周更包中同版本的构建便不再具有独立价值，删除可释放项目存储。

3.2 操作步骤

1. 打开 onnx-weekly 发布管理页面；
2. 选中过期版本，核验其版本号与文件列表；
3. 使用Options > Delete移除该版本。

3.3 访问控制注意

onnx-weekly与onnx是两个独立的 PyPI 项目，访问控制相互分离。如果你需要管理周更包但当前没有权限，应向现有项目所有者申请访问权限。

四、清理场景二：TestPyPI 发布候选（Release Candidates）

4.1 清理时机与对象

在以下两个条件同时满足后，管理员可以删除 TestPyPI 上过期的 ONNX RC distribution：

1. 对应的稳定版本已经发布；
2. 合作伙伴验证已完成。

同时要保留仍然需要用于调查当前版本的候选版本——也就是说，如果当前版本还存在未解决的回归问题、需要对照某个 RC 复现分析，则该 RC 应予以保留。

4.2 操作步骤

1. 打开 ONNX TestPyPI 发布管理页面；
2. 选中过期的候选版本，核验其版本号与文件列表；
3. 使用Options > Delete移除该版本。

4.3 RC 在发布流程中的位置

RC 版本由 GitHub Actions 工作流自动构建并上传。在 .github/workflows/create_release.yml 中可以看到，publish_testpypi_release输入项专门负责将rel-分支上的候选构建发布到 TestPyPI（对应testpypi-release部署环境，目标地址 https://test.pypi.org/p/onnx）；publish_pypi_release则负责最终发布到正式 PyPI（对应pypi-release环境）。此外，工作流还通过check_for_publish_release_build_to_pypi等守卫作业校验VERSION_NUMBER与分支名的一致性（允许X.Y.Z或X.Y.Zrc*格式），从流程上保证 RC 与正式版的版本命名规范。

五、与完整发布流程的衔接

5.1 清理动作发生在发布链路的末端

存储清理不是孤立操作，而是 ONNX 发布生命周期（约每 3 个月一个周期）的收尾环节。整体链路为：

1. 准备：确定版本X.Y.Z，创建rel-X.Y.Z分支，准备初步发布说明（新特性、Bug 修复、已知问题、弃用与移除项），标签体系见 .github/release.yml；
2. 候选验证：通过 Create Releases 工作流构建各平台 wheel 与 sdist，发布 RC 到 TestPyPI，供 onnxruntime、PyTorch、tensorflow-onnx 等合作伙伴验证；
3. 正式发布：验证通过后移除rcX后缀、创建 git tag、发布正式版到 PyPI（自 1.19 起 RC 也直接发布到 PyPI，此前使用 test.pypi.org）；
4. 发布后收尾：公告、更新 conda-forge feedstock、将发布分支合并回 main；
5. 存储清理（本文主题）：由 Architecture & Infra SIG 管理员删除过期的onnx-weekly版本与 TestPyPI RC。

在 docs/OnnxReleases.md 的末尾明确写道："PyPI storage cleanup is not part of the release manager's responsibilities. It is performed separately by Architecture & Infra SIG administrators as described in Release Administration."——这正是本文所述管理任务在整体流程中的官方定位。

5.2 发布可追溯性与安全验证

清理操作只影响存储层面，不影响已发布包的完整性验证。ONNX 自 1.20 起为 PyPI 发行版附加符合PEP 740的Sigstore 签名证明（attestations），可校验制品未被篡改、确由 ONNX CI 构建并发布、发布者身份为onnx/onnx，验证方法详见 docs/ReleaseVerification.md。管理员在删除旧版本前，可先据此确认归档制品的可信性再执行清理。

六、最佳实践小结

• 先协调后操作：与 Architecture & Infra SIG 确认清理范围与时机；
• 三要素核验：项目、版本、包类型与目标索引，缺一不可；
• 区分索引实例：TestPyPI 的 RC 清理与 PyPI 的onnx-weekly清理是两套独立流程，使用各自的管理页面；
• 保留在途证据：当前版本调查仍需要的 RC 不要删除；
• 注意权限边界：onnx-weekly与onnx访问控制分离，需要单独申请；
• 删除即终局：PyPI 上已发布的版本不可覆盖，正式发布前务必在 TestPyPI 上确认一切正确（详见 docs/OnnxReleases.md 的 NOTES）。

参考资料

• docs/ReleaseAdministration.md：本文的直接来源，定义管理员清理职责与步骤
• docs/OnnxReleases.md：完整发布流程（准备、分支、RC、正式发布、收尾）
• RELEASE-MANAGEMENT.md：发布节奏、兼容性矩阵、周更包机制
• .github/workflows/create_release.yml：Create Releases 工作流，含 TestPyPI/PyPI 发布与版本校验守卫
• .github/release.yml：发布说明生成所用的 PR 标签分类
• docs/ReleaseVerification.md：Sigstore / PEP 740 发布验证
• onnx/init.py：onnx与onnx-weekly版本号共存读取逻辑

• 人工智能
• 深度学习
• 机器学习