发布管理指南¶

本页面提供了执行发布所遵循步骤的详细信息。它既可以用作学习 ADBC 发布流程的指南，也可以作为发布经理在执行发布时的综合检查清单。

另请参阅

Apache Arrow 发布管理指南

原则¶

Apache Arrow 发布遵循 Apache 软件基金会发布政策中定义的准则。

发布准备¶

发布的一些步骤需要是提交者或 PMC 成员。

Apache 信任网络中的 GPG 密钥用于签署工件。该密钥必须由其他 Apache 提交者/PMC 成员交叉签名。您必须在 dev/release/.env 中设置您的 GPG 密钥 ID（参见 dev/release/.env.example 以获取模板）。
GPG 密钥需要添加到此 SVN 仓库和此仓库中。
配置 Maven 以将制品发布到 Apache 仓库。你需要按照 Apache 指南的说明，在 ~/.m2/settings-security.xml 和 settings.xml 中设置主密码。可以通过以下命令进行测试
```
# You might need to export GPG_TTY=$(tty) to properly prompt for a passphrase
mvn clean install -Papache-release
```
一个 Artifactory API 密钥（使用您的 ASF 凭据登录，然后从右上角的个人资料中生成）。您必须在 dev/release/.env 中设置 Artifactory API 密钥（参见 dev/release/.env.example 以获取模板）。
安装 en_US.UTF-8 区域设置（locale）。你可以通过 locale -a 确认可用的区域设置。
安装带有 conda-forge 的 Conda，并创建并激活环境。
```
mamba create -n adbc -c conda-forge --file ci/conda_env_dev.txt
```
这将安装发布过程中使用的两个工具：commitizen（根据提交信息生成变更日志）和 gh（提交作业/下载制品）。
安装 Docker。
克隆主 Arrow 仓库（https://github.com/apache/arrow）并将 arrow-adbc/dev/release/.env 软链接到 arrow/dev/release/.env。一些发布脚本依赖于主 Arrow 仓库中的脚本。

创建发布候选版本（RC）之前¶

重新生成 LICENSE.txt（参见 CONTRIBUTING.md），如果需要进行任何更改，请创建一个拉取请求（PR）。

设置你的 Shell 环境

# Setup gpg agent for signing artifacts
source dev/release/setup-gpg-agent.sh

# Activate conda environment
mamba activate adbc

确保合并的拉取请求和已关闭的问题已正确设置里程碑（milestone）
```
./dev/release/assign-milestone.sh
```

检查每日验证作业¶

确保验证作业通过。这模拟了部分发布验证工作流，以便提前发现问题。

创建发布候选版本¶

这些是创建发布候选版本所需的各个步骤。

对于初始发布候选版本，我们将从主分支（master）创建一个维护分支。后续的发布候选版本将通过拣选（cherry-pick）特定提交来更新维护分支。

我们在发布候选版本之间实施了功能冻结（Feature Freeze）政策。这意味着，通常情况下，我们只应在发布候选版本之间添加错误修复。在极少数情况下，如果社区达成共识，可以在发布候选版本之间添加关键功能。

创建或更新相应的维护分支¶

初始发布候选版本

# Execute the following from an up to date master 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
git branch maint-X.Y.Z
# Push the maintenance branch to the remote repository
git push -u apache maint-X.Y.Z

后续发布候选版本

git switch maint-X.Y.Z
# Remove the commits that created the changelog and bumped the
# versions, since 01-prepare.sh will redo those steps
git reset --hard HEAD~2
# Cherry-pick any commits by hand.
git cherry-pick ...
# Push the updated maintenance branch to the remote repository
git push -u apache maint-X.Y.Z

从更新后的维护分支创建发布候选版本标签¶

# Start from the updated maintenance branch.
git switch maint-X.Y.Z

# The following script will create a branch for the Release Candidate,
# place the necessary commits updating the version number and changelog, 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 1.0.0 0

dev/release/01-prepare.sh <arrow-dir> <rc-number>

git push -u apache apache-arrow-adbc-<release>-rc<rc-number> maint-<release>

构建源代码和二进制文件并提交它们¶

# Download the produced source and binaries, sign them, and add the
# signatures to the GitHub release
#
# 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/02-sign.sh <rc-number>

# Upload the source release tarball and signs to
# https://dist.apache.org/repos/dist/dev/arrow .
dev/release/03-source.sh <rc-number>

# Upload the Java artifacts
#
# Note that you need to press the "Close" button manually in the Web
# interface after you complete the script:
#   https://repository.apache.org/#stagingRepositories
dev/release/04-java-upload.sh <rc-number>

# Sign and upload the deb/rpm packages and APT/Yum repositories
#
# This reuses release scripts in apache/arrow. So you need to
# specify cloned apache/arrow directory.
dev/release/05-linux-upload.sh <arrow-dir> <rc-number>

# Start verifications for binaries and wheels
dev/release/06-binary-verify.sh <rc-number>

验证发布¶

使用 06-binary-verify.sh 中的电子邮件模板，在 dev@arrow.apache.org 上启动投票帖。

投票与批准¶

在 dev@arrow.apache.org 上启动投票帖，并提供验证发布完整性的说明。批准需要来自 PMC 成员的净 3 张 +1 票。发布不能被否决。

如何验证发布候选版本¶

安装依赖项。至少需要：
- cURL
- Docker（用于验证二进制文件）
- Git
- GnuPG
- shasum（内置于 macOS）或 sha256sum/sha512sum（在 Linux 上）
你还需要安装构建和验证所有语言所需的所有依赖项。大致来说，这意味着：
- C 和 C++ 编译器（或你平台上相当于 build-essential 的工具）
- Python 3
- 带有头文件的 Ruby
  - 需要 meson
- bundler、rake、red-arrow 和 test-unit Ruby gems
- 带有头文件的 GLib 和 gobject-introspection
  - pkg-config 或 cmake 必须能够找到 libarrow-glib.so
  - GI_TYPELIB_PATH 应设置为 girepository-1.0 目录的路径
- Java JRE 和 JDK (Java 11+)
  - javadoc 命令也必须可访问
- Go
- CMake, ninja-build, libpq（带头文件）, SQLite（带头文件）
- Node.js 22+
或者，你可以让验证脚本通过 Conda 自动下载并安装依赖项。请参阅下面的环境变量。

克隆项目

$ git clone https://github.com/apache/arrow-adbc.git

运行验证脚本
```
$ cd arrow-adbc
# Pass the release and the RC number
$ ./dev/release/verify-release-candidate.sh 0.1.0 6
```
这些环境变量可能会有所帮助
- ARROW_TMPDIR=/path/to/directory 用于指定使用的临时目录。使用固定目录有助于避免在脚本必须多次运行时重复相同的设置和构建步骤。
- USE_CONDA=1 以下载并设置 Conda 来管理依赖项。在这种情况下，系统所需的依赖项较少。（但仍需要 Git, GnuPG, cURL 等。）
一旦完成且脚本通过，请在邮件列表的投票帖中回复 +1 或 -1。

发布后任务¶

发布投票通过后，我们必须执行多项任务来更新源代码制品、二进制构建和 Arrow 网站。

请确保逐一核对以下清单：