发布流程
标准发布流程¶
1. 确定版本名称¶
注意
版本名称总是以 v
开头。
版本名称示例
"vX.Y" # Release major version X (starts at 0), minor version Y (starts at 1).
"vX.Y.Z" # Release major version X (starts at 0), minor version Y (starts at 1), patch Z (starts at 1).
"vX.YrcZ" # Release candidate Z, without a period. (starts at 1)
"vX.Y.dev" # Developer version, with a period.
灵感来源
2. 更新代码中的 Ludwig 版本¶
从 target_release_branch(例如 master
或 release-X.Y
)创建一个新分支。
git checkout <TARGET_RELEASE_BRANCH>
git checkout -b ludwig_release
git push --set-upstream origin ludwig_release
更新 globals 和 setup 中引用的版本。参考 PR。
git commit -m "Update ludwig version to vX.YrcZ."
git push
创建一个包含更改的 PR,请求从 ludwig_release
合并到目标分支。
获得 Ludwig 维护者 的批准。
合并 PR(使用 squash)。
3. 标记最新的 commit,并推送标签¶
合并步骤 2 的 PR 后,target_release_branch 上的最新 commit 应该是升级 Ludwig 版本的 PR。
从 HEAD 拉取更改。
git checkout <TARGET_RELEASE_BRANCH>
git pull
在本地为该 commit 添加标签
git tag -a vX.YrcZ -m "Ludwig vX.YrcZ"
将标签推送到仓库。
git push --follow-tags
4. 在 Github 上,前往 releases 并“Draft a new release”(创建新的发布草稿)¶
Loom 演练。
发布候选版本不需要发布说明。正式发布版本应该有详细的发布说明。所有发布都应包含完整的更改列表(Github 支持自动生成)。
请勿手动上传资产。这些将由 Github 自动创建。
对于发布候选版本,请勾选“pre-release”。
5. 点击发布¶
发布说明准备好后,在 Github 上点击 Publish release
。Ludwig 的 CI 将自动更新 PyPI。
6. 更新 Ludwig 文档¶
检查 Ludwig PyPi 是否已更新到最新版本。
前往 ludwig-docs 仓库并更新那里的自动生成文档。
> cd ludwig-docs
> git pull
> git checkout -b update_docs
> pip install ludwig --upgrade
> python code_doc_autogen.py
如果有任何更改,提交它们。
> git commit -m "Update auto-generated docs."
> git push --set-upstream origin update_docs
创建 PR。
7. 对于主要版本,创建 release-X.Y 分支¶
> git checkout master
> git checkout -b release-X.Y
> git push --set-upstream origin release-X.Y
在此主要版本之上的所有后续次要版本都将基于此分支。
8. 宣传发布¶
在 Slack 上宣布发布。
Ludwig X.Y.Z Released
Features: Improvements to <CONTENT>. See <LINK>release notes<LINK> for complete details.
Docs: https://ludwig.net.cn/latest/
如果是主要版本发布,考虑其他形式的宣传,如协调在其他社交媒体上分享发布,或撰写博客文章。
将 master 分支上的 bugfix commits 合并到稳定发布分支¶
1. 收集需要合并的 commit hashes 列表¶
您可以使用 git log
中的完整哈希,或 Github PR UI 中的部分哈希,例如:
2. 在 cherrypick-X.Y 分支中合并每个 commit¶
git checkout release-X.Y
git checkout -b cherrypick-X.Y
git cherry-pick <commit_1> # One commit at a time.
git cherry-pick <commit_2> <commit_3> <commit_4> ... # Or multiple commits all at once.
确保所有 cherry-picks 都已正确应用。
注意
空的 cherry-picks 可能意味着该 commit 已存在。
3. 创建包含合并更改的 PR,合并到 release-X.Y
¶
推送 cherrypick 分支。
git push --set-upstream origin cherrypick-X.Y
创建一个包含更改的 PR,请求从 cherrypick-X.Y
合并到 release-X.Y
。
获得 Ludwig 维护者 的批准。
合并 PR,不要 使用 squash。
继续进行 标准发布流程。
附录¶
哎呀,在版本升级后又有更多 PR 被合并了¶
如果在版本升级后有一些最后一刻的 PR 被合并了,请重新排序 commits,使版本升级成为在发布前被标记的最后一个 commit。
哎呀,我标记了错误的 commit,并且已经推送到 github 了¶
git tag -d <tagname> # delete the old tag locally
git push origin :refs/tags/<tagname> # delete the old tag remotely
git tag <tagname> <commitId> # make a new tag locally
git push origin <tagname> # push the new local tag to the remote