发布管理指南#
本页面详细介绍了执行发布的步骤。它既可以作为学习 Apache Arrow 发布流程的指南，也可以作为发布经理执行发布时的全面清单。担任发布经理的人员至少必须具有 committer 身份才能执行以下任务。如果发布经理是 committer 但不是 PMC 成员，则某些任务需要委托给 PMC 成员，这些任务在下面已相应标记。
原则#
Apache Arrow 发布遵循 Apache 软件基金会发布政策中定义的准则。
准备发布#
在发布日期之前，发布经理通常通过 Zulip、邮件列表或每两周一次的社区电话与社区沟通即将发布的版本，并提出一个功能冻结日期。
功能冻结日期是创建维护分支的日期，从那时起，除非社区达成共识，否则不允许向版本添加新功能，并且只接受错误修复。
一旦功能冻结到位，标记为 blocker 的问题必须在创建第一个候选版本之前解决。
在创建候选版本之前，发布经理必须确保任何已解决的 GitHub 问题都已设置适当的里程碑，以便正确生成更新日志。
请注意，没有相应 GitHub Issue 的拉取请求不会被 cherry-pick 脚本检测到，并且必须由发布经理手动 cherry-pick 到维护分支。示例包括 MINOR 和 Dependabot 拉取请求。因此，建议在创建发布维护分支后，为合并到默认分支的任何拉取请求创建 Issue，以避免手动 cherry-pick 的需要。
创建候选版本之前#
确保本地标签已删除，gpg-agent 已设置，并且 GitHub 问题已正确分配。
# Delete the local tag for RC1 or later
git tag -d apache-arrow-<version>
# Setup gpg agent for signing binary artifacts
source dev/release/setup-gpg-agent.sh
# Curate the release
# The end of the generated report shows any GitHub issues with the wrong
# version number assigned.
archery release curate <version>
确保在 GitHub 上为后续版本创建了一个主要版本里程碑。当创建维护分支时，我们的合并脚本将自动使用它作为已关闭问题的新版本。
补丁版本#
我们通常在发现了一个重大破坏性问题后创建补丁版本。被认定为重大破坏性问题的问题可以是安全修复、特定构建的损坏包等。
任何开发人员都可以通过向 Arrow 开发邮件列表发送电子邮件，说明需要新版本的原因，来请求生成补丁版本。如果达成共识并且有发布经理愿意努力创建该版本，则可以创建补丁版本。
提交者可以使用 backport-candidate 标签标记应包含在下一个补丁版本中的问题。作者或提交者有责任将标签添加到问题中，以帮助发布经理识别应向后移植的问题。
如果某个特定问题被认定为创建补丁版本的原因，发布经理应验证，至少，该问题已正确标记并包含在补丁版本中。
请务必仔细检查以下清单
创建里程碑
创建维护分支
包含作为需要新补丁版本而被请求的问题
将新里程碑添加到带有
backport-candidate标签的问题将问题 cherry-pick 到维护分支
创建候选版本#
这些是创建候选版本所需的各种步骤。
对于主要版本的初始候选版本，我们将从 main 创建一个维护分支。这在功能冻结日期完成。
后续的候选版本将通过 cherry-pick 特定提交来更新维护分支。
对于次要版本或补丁版本的初始候选版本，我们将从前一个相应的版本创建维护分支。例如，对于 15.0.1 补丁，我们将从 maint-15.0.0 创建 maint-15.0.1 分支，对于 maint-15.0.2，我们将从 maint-15.0.1 创建。创建维护分支后，我们将通过 cherry-pick 特定提交来更新创建的维护分支。
创建或更新相应的维护分支#
# Execute the following from an up to date main branch.
# This will create a branch locally called maint-X.Y.Z.
# X.Y.Z corresponds with the Major, Minor and Patch version number
# of the release respectively. As an example 9.0.0
archery release cherry-pick X.Y.Z --execute
# Push the maintenance branch to the remote repository
git push -u upstream maint-X.Y.Z
# First run in dry-mode to see which commits will be cherry-picked.
# If there are commits that we don't want to get applied, ensure the
# milestone on GitHub is set to the following release.
archery release cherry-pick X.Y.Z --continue
# Update the maintenance branch with the previous commits
archery release cherry-pick X.Y.Z --continue --execute
# Push the updated maintenance branch to the remote repository
git push -u upstream maint-X.Y.Z
可选：在创建候选版本之前进行测试#
一些发布经理更喜欢在创建第一个候选版本之前执行测试，以避免在给定发布中创建多个候选版本。
在创建候选版本之前进行测试
从最新的 maint-X.Y.Z 分支向 main 创建拉取请求
将拉取请求标题命名为“WIP: Dummy PR to check maint-X.Y.Z status”
在拉取请求上评论以触发相关的 Crossbow 作业
@github-actions crossbow submit --group verify-rc-source@github-actions crossbow submit --group packaging
从更新的维护分支创建候选发布分支#
# Start from the updated maintenance branch.
git checkout maint-X.Y.Z
# The following script will create a branch for the Release Candidate,
# place the necessary commits updating the version number and then create a git tag
# on OSX use gnu-sed with homebrew: brew install gnu-sed (and export to $PATH)
#
# <rc-number> starts at 0 and increments every time the Release Candidate is created
# so for the first RC this would be: dev/release/01-prepare.sh 4.0.0 5.0.0 0
dev/release/01-prepare.sh <version> <next-version> <rc-number>
# Push the release candidate tag
git push -u upstream apache-arrow-<version>-rc<rc-number>
# Push the release candidate branch in order to trigger verification jobs later
git push -u upstream release-<version>-rc<rc-number>
一旦创建了标签，verify-rc.yml 上的 GitHub Actions 工作流将被触发以验证候选版本。
release_candidate.yml 工作流也将被触发，它将签署发布源代码并创建一个带有相应源代码和签名的 GitHub 预发布版本。
构建源代码和二进制文件并提交它们#
# Waits for previous workflows to finish and uploads source and signatures to SVN.
#
# NOTE: This must be run by a PMC member
# NOTE: You need to have GitHub CLI installed to run this script.
dev/release/02-source.sh <version> <rc-number>
# Submit binary tasks using crossbow, the command will output the crossbow build id
dev/release/03-binary-submit.sh <version> <rc-number>
# Wait for the crossbow jobs to finish
archery crossbow status <crossbow-build-id>
# Download the produced binaries
# This will download packages to a directory called packages/release-<version>-rc<rc-number>
dev/release/04-binary-download.sh <version> <rc-number>
# Sign and upload the binaries
#
# NOTE: This must be run by a PMC member
#
# On macOS the only way I could get this to work was running "echo "UPDATESTARTUPTTY" | gpg-connect-agent" before running this comment
# otherwise I got errors referencing "ioctl" errors.
dev/release/05-binary-upload.sh <version> <rc-number>
# Sign and upload MATLAB artifacts to the GitHub Releases area.
#
# NOTE: This must be run by a PMC member
# NOTE: You need to have GitHub CLI installed to run this script.
dev/release/06-matlab-upload.sh <version> <rc-number>
# Start verifications for binaries and wheels
dev/release/07-binary-verify.sh <version> <rc-number>
验证发布#
# Once the automatic verification has passed start the vote thread
# on dev@arrow.apache.org. To regenerate the email template use
SOURCE_DEFAULT=0 SOURCE_VOTE=1 dev/release/02-source.sh <version> <rc-number>
有关详细信息，请参阅发布验证过程。
投票和批准#
在 dev@arrow.apache.org 上启动投票线程，并提供验证发布完整性的说明。批准需要至少 3 票来自 PMC 成员的 +1 票。发布不能被否决。
发布后任务#
发布投票后，我们必须承担许多任务来更新源代码工件、二进制构建和 Arrow 网站。
请务必仔细检查以下清单
更新已发布的里程碑日期并将其设置为 GitHub 上的“Closed”
将发布分支上的更改合并到补丁版本的维护分支
将新版本添加到 Apache Reporter System
推送发布标签
上传源代码
上传二进制文件
更新网站
更新 GitHub 发布说明
更新 Homebrew 包
更新 MSYS2 包
上传 RubyGems
更新 conda 配方
上传 wheels/sdist 到 pypi
更新 R 包
更新 vcpkg 端口
更新 Conan recipe
提升版本
更新文档
更新 Apache Arrow Cookbook 中的版本
宣布新发布
发布发布博客文章
在 BlueSky 上宣布发布
删除旧工件