版本管理指南#
此页面详细介绍了执行发布的步骤。它既可以用作学习 Apache Arrow 发布流程的指南，也可以作为发布管理员执行发布时的全面清单。担任发布管理员的人员必须至少具有提交者状态才能执行以下任务。如果发布管理员是提交者但不是 PMC 成员，则需要将某些任务委派给 PMC 成员，这些任务将在下面进行相应标记。
原则#
Apache Arrow 版本遵循Apache 软件基金会发布政策中定义的准则。
准备发布#
在创建源代码版本之前，版本管理员必须确保所有已解决的 GitHub 问题都设置了适当的里程碑，以便正确生成变更日志。
请注意，没有相应 GitHub 问题的拉取请求不会被 cherry-pick 脚本检测到，必须由版本管理员手动 cherry-pick 到维护分支上。例如 MINOR 和 Dependabot 拉取请求。因此，建议通过为发布维护分支创建后合并到默认分支的任何拉取请求创建问题，来避免手动 cherry-pick 的需要。
创建候选版本之前#
确保已删除本地标签，已设置 gpg-agent 并且 GitHub 问题已正确分配。
# Delete the local tag for RC1 or later
git tag -d apache-arrow-<version>
# Setup gpg agent for signing 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 到维护分支
创建候选版本#
以下是创建候选版本所需的 fabbricazione步骤。
对于主要版本上的初始候选版本，我们将从主版本创建维护分支。
后续候选版本将通过 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 apache 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 apache maint-X.Y.Z
可选：在创建候选版本之前进行测试#
一些版本管理员更喜欢在创建第一个候选版本之前执行测试，以避免在给定版本中创建多个候选版本的需要。
要在创建候选版本之前进行测试
从最新的 maint-X.Y.Z 分支到主分支创建一个拉取请求
将拉取请求命名为“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 apache apache-arrow-<version>-rc<rc-number>
# Push the release candidate branch in order to trigger verification jobs later
git push -u apache release-<version>-rc<rc-number>
构建源代码和二进制文件并提交它们#
# Build the source release tarball and create Pull Request with verification tasks
#
# 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 [email protected]. To regenerate the email template use
SOURCE_DEFAULT=0 SOURCE_VOTE=1 dev/release/02-source.sh <version> <rc-number>
有关详细信息，请参阅 版本验证流程。
投票和批准#
在 dev@arrow.apache.org 上启动投票线程，并提供验证版本完整性的说明。批准需要 PMC 成员的 3 个 +1 票（净票数）。版本不能被否决。
发布后任务#
发布投票结束后，我们需要完成许多任务来更新源代码工件、二进制构建文件和 Arrow 网站。
确保完成以下清单
在 GitHub 上更新已发布里程碑的日期并将其设置为“已关闭”。
将发布分支上的更改合并到维护分支，以便进行补丁发布。
将新版本添加到 Apache 报告系统。
推送发布标签。
上传源代码。
上传二进制文件。
更新网站。
更新 GitHub 发布说明。
更新 Homebrew 软件包。
更新 MSYS2 软件包。
上传 RubyGems。
上传 JavaScript 软件包。
上传 C# 软件包。
更新 conda 配方。
将 wheel/sdist 上传到 PyPI。
更新 R 软件包。
更新 vcpkg 端口。
更新 Conan 配方。
更新版本号。
更新文档。
更新 Apache Arrow Cookbook 中的版本。
宣布新版本发布。
发布版本博客文章。
在 Twitter 上宣布新版本发布。
删除旧工件。