版本发布管理指南#

此页面提供了有关执行版本发布步骤的详细信息。它既可以作为学习 Apache Arrow 版本发布流程的指南，也可以作为版本发布经理在执行版本发布时使用的综合检查清单。

原则#

Apache Arrow 版本发布遵循Apache 软件基金会版本发布策略中定义的指南。

准备发布#

在创建源代码版本之前，版本发布经理必须确保任何已解决的 JIRA 问题都设置了正确的修复版本，以便正确生成变更日志。

在创建候选版本之前#

确保已删除本地标签、已设置 gpg-agent 且 JIRA 票证已正确分配。

# 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 the JIRA tickets with wrong version number assigned.
archery release curate <version>

确保在 GitHub 上为后续版本创建主要版本里程碑。当创建维护分支时，我们的合并脚本将自动将此用作已关闭问题的版本。

修补程序版本#

我们通常在发现主要问题后创建修补程序版本。被识别为主要问题的错误可能是安全修复、特定构建的损坏包等。

任何开发人员都可以请求生成修补程序版本，方法是向Arrow 开发邮件列表发送电子邮件，说明为什么需要新版本。如果达成共识，并且有版本发布经理愿意承担创建版本的工作，则可以创建修补程序版本。

提交者可以使用backport-candidate标签标记应包含在下一个修补程序版本中的问题。作者或提交者有责任将标签添加到问题中，以帮助版本发布经理识别应回传的问题。

如果识别出特定问题是创建修补程序版本的原因，则版本发布经理应验证至少此问题是否已正确标记并包含在修补程序版本中。

请务必完成以下检查清单

创建里程碑
创建维护分支
包含请求为需要新修补程序版本的问题
将新里程碑添加到带有backport-candidate标签的问题中
将问题 cherry-pick 到维护分支中

创建候选版本#

这些是在创建候选版本时需要执行的不同步骤。

对于主要版本的初始候选版本，我们将从主分支创建维护分支。

后续的候选版本将通过 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 --jira-cache /tmp/jiracache 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 version on
# JIRA is set to the following release.
archery release --jira-cache /tmp/jiracache cherry-pick X.Y.Z --continue
# Update the maintenance branch with the previous commits
archery release --jira-cache /tmp/jiracache cherry-pick X.Y.Z --continue --execute
# Push the updated maintenance branch to the remote repository
git push -u apache maint-X.Y.Z

从更新的维护分支创建候选版本分支#

# 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 burned
# 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: 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
#
# 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 the Java artifacts
#
# Note that you need to press the "Close" button manually by Web interface
# after you complete the script:
#   https://repository.apache.org/#stagingRepositories
dev/release/06-java-upload.sh <version> <rc-number>

# Sign and upload MATLAB artifacts to the GitHub Releases area.
#
# Note that you need to have GitHub CLI installed to run this script.
dev/release/07-matlab-upload.sh <version> <rc-number>

# Start verifications for binaries and wheels
dev/release/08-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 上设置为“已关闭”
将 CPP PARQUET 相关版本在 JIRA 上标记为“已发布”
在 JIRA 上为相关的 CPP PARQUET 版本开始新版本
将发布分支上的更改合并到修补程序版本的维护分支中
将新版本添加到 Apache Reporter 系统
推送发布标签
上传源代码
上传二进制文件
更新网站
更新 GitHub 版本说明
更新 Homebrew 软件包
更新 MSYS2 软件包
上传 RubyGems
上传 JavaScript 软件包
上传 C# 软件包
更新 conda 配方
将轮子/sdist 上传到 pypi
发布 Maven 工件
更新 R 软件包
更新 vcpkg 端口
更新 Conan 配方
更新版本号
更新 Go 模块的标签
更新文档
更新 Apache Arrow 食谱中的版本号
宣布新版本
发布版本博文
在 Twitter 上宣布版本发布
删除旧工件