PyMC 发布工作流程

• 通过 特定版本的 里程碑 跟踪所有相关的问题和PR。

• 确保没有已知的主要错误不应被发布。

• 向 __init__.py 提交 PR 更新版本号 并编辑 RELEASE-NOTES.md。

  • 重要

    请不要以发布版本本身命名，并记得像普通公民一样推送到你自己的分支。

  • 在顶部创建一个新的“vNext”部分

  • 编辑带有发布版本和日期的标题

  • 在发布中添加一行以表彰发布经理，就像之前的发布一样

• 合并PR后，检查主分支上的CI管道是否全部通过✔

• 使用标签 ´v1.2.3´ 创建一个发布，并提供一个人类可读的标题，类似于之前的发布。

最后一步完成后，GitHub Action “release-pipeline” 会被触发，自动构建并将新版本发布到 PyPI。

故障排除

• 如果由于某些原因，发布必须被“取消发布”，这可以通过在PyPI和GitHub上手动删除来实现。然而，PyPI将不会接受另一个具有相同版本号的发布！

• release-pipeline 有一个 test-install-job，如果 PyPI 索引更新不够快，该作业可能会失败。

发布后步骤

• 前往 Zenodo 并将特定版本的 DOI-bade 复制到 发布说明 中

• 重命名并关闭发布里程碑，并开启一个新的“vNext”里程碑

• 监控 conda-forge/pymc-feedstock 仓库的新PR。机器人应该会自动识别新版本并打开一个PR来更新它。不过，可能需要手动干预（参见仓库的PR历史以获取示例）。

• 使用新版本重新运行笔记本（参见 https://github.com/pymc-devs/pymc-examples）

• 确保新版本出现在网站上，并且 docs.pymc.io/en/stable 指向它。