發佈管理指南#

此頁面提供關於執行發佈的詳細步驟資訊。它可以用作學習 Apache Arrow 發佈流程的指南，以及發佈管理員在執行發佈時的完整檢查清單。擔任發佈管理員的人員必須至少具有提交者身分才能執行以下任務。如果發佈管理員是提交者但不是 PMC 成員，則某些任務需要委派給 PMC 成員，這些任務在下方會相應標記。

原則#

Apache Arrow 發佈遵循 Apache 軟體基金會發佈政策中定義的準則。

準備發佈#

在建立來源發佈之前，發佈管理員必須確保任何已解決的 GitHub issue 都已設定適當的里程碑，以便正確產生變更日誌。

請注意，沒有對應 GitHub issue 的 pull request 不會被 cherry-pick 腳本偵測到，必須由發佈管理員手動 cherry-pick 到維護分支。範例包括 MINOR 和 Dependabot pull request。因此，建議為在發佈維護分支建立後合併到預設分支的任何 pull request 建立 issue，以避免需要手動 cherry-pick。

在建立發佈候選版本之前#

確保移除本機標籤、設定 gpg-agent，且正確指派 GitHub issue。

# 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 上為後續發佈建立主要版本里程碑。我們的合併腳本將自動使用此里程碑作為在建立維護分支時關閉的 issue 的新版本。

修補程式發佈#

我們通常在識別出主要破壞性問題後建立修補程式發佈。被識別為主要破壞性問題的問題可能是安全性修復、特定建置的套件損壞以及其他問題。

任何開發人員都可以要求產生修補程式發佈，方法是發送電子郵件到 Arrow 開發郵件列表，說明為何需要新發佈的原因。如果達成共識並且有發佈管理員願意付出努力建立發佈，則可以建立修補程式發佈。

提交者可以使用 backport-candidate 標籤標記應包含在下一個修補程式發佈中的 issue。作者或提交者有責任將標籤新增到 issue，以協助發佈管理員識別應回溯移植的 issue。

如果特定 issue 被識別為建立修補程式發佈的原因，則發佈管理員應驗證至少此 issue 已正確標記並包含在修補程式發佈中。

請務必完成以下檢查清單

建立里程碑
建立維護分支
包含要求作為新修補程式發佈的問題
將新里程碑新增到具有 backport-candidate 標籤的 issue
將 issue cherry-pick 到維護分支

建立發佈候選版本#

以下是建立發佈候選版本所需的不同步驟。

對於主要發佈的初始發佈候選版本，我們將從 main 建立維護分支。

後續發佈候選版本將透過 cherry-pick 特定 commit 來更新維護分支。

對於次要或修補程式發佈的初始發佈候選版本，我們將從先前的對應發佈建立維護分支。例如，對於 15.0.1 修補程式，我們將從 maint-15.0.0 建立 maint-15.0.1 分支，對於 maint-15.0.2，我們將從 maint-15.0.1 建立。建立維護分支後，我們將透過 cherry-pick 特定 commit 來更新建立的維護分支。

我們已實施發佈候選版本之間的「功能凍結」政策。這表示一般而言，我們應該只在發佈候選版本之間新增錯誤修復。在極少數情況下，如果社群達成共識，則可以在發佈候選版本之間新增關鍵功能。

建立或更新對應的維護分支#

初始發佈候選版本

# 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 分支建立 pull request 到 main
將 pull request 標題設為「WIP: Dummy PR to check maint-X.Y.Z status」
在 pull request 上評論以觸發相關的 Crossbow job
- @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 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 上啟動投票討論串，並提供驗證發佈完整性的說明。批准需要 PMC 成員的淨額 3 個 +1 票。發佈不能被否決。

發佈後任務#

在發佈投票後，我們必須執行許多任務來更新來源工件、二進位建置和 Arrow 網站。

請務必完成以下檢查清單

更新已發佈里程碑的日期，並在 GitHub 上設定為「已關閉」
合併發佈分支上的變更到修補程式發佈的維護分支
將新發佈新增到 Apache Reporter System
推送發佈標籤
上傳來源
上傳二進位檔
更新網站
更新 GitHub 發佈說明
更新 Homebrew 套件
更新 MSYS2 套件
上傳 RubyGems
上傳 JavaScript 套件
上傳 C# 套件
更新 conda 食譜
上傳 wheels/sdist 到 pypi
更新 R 套件
更新 vcpkg port
更新 Conan 食譜
Bump 版本
更新文件
更新 Apache Arrow Cookbook 中的版本
公告新發佈
發佈發佈部落格文章
在 Twitter 上公告發佈
移除舊工件