發佈檢查清單

維護者發佈 Helm 的指南

是時候發佈新的 Helm 版本了！作為發佈 Helm 的維護者，您最適合根據自己的經驗更新此發佈檢查清單，如果您的經驗與這裡記錄的不同。

所有版本都採用 vX.Y.Z 的形式，其中 X 是主要版本號，Y 是次要版本號，Z 是修補程式版本號。此專案嚴格遵循語義化版本控制，因此遵循此步驟至關重要。

Helm 會提前宣布其下一個次要版本的發佈日期。應盡一切努力遵守宣布的日期。此外，在開始發佈流程時，應已選擇下一個版本的日期，因為它將在發佈流程中使用。

這些說明將涵蓋初始設定，然後是三種不同類型版本的發佈流程

主要版本 - 發佈頻率較低 - 具有重大變更
次要版本 - 每 3 到 4 個月發佈一次 - 沒有重大變更
修補程式版本 - 每月發佈 - 不需要本指南中的所有步驟

初始設定

建立發佈分支
主要/次要版本：在 Git 中變更版本號
主要/次要版本：提交並推送發佈分支
主要/次要版本：建立候選版本
主要/次要版本：迭代 successive 候選版本
完成發佈
撰寫版本說明
使用 PGP 簽署下載檔案
發佈版本
更新文件
告知社群

初始設定

設定 Git 遠端

請務必注意，本文檔假設您的儲存庫中對應於 https://github.com/helm/helm 的 git 遠端名稱為「upstream」。如果您的名稱不是（例如，如果您選擇將其命名為「origin」或其他類似名稱），請務必相應地調整本地環境的列出程式碼片段。如果您不確定您的 upstream 遠端名稱是什麼，請使用 git remote -v 之類的命令找出。

如果您沒有 upstream 遠端，您可以使用以下方法新增一個

git remote add upstream git@github.com:helm/helm.git

設定環境變數

在本文檔中，我們還將參考一些環境變數，您可能希望為了方便起見設定這些變數。對於主要/次要版本，請使用以下內容

export RELEASE_NAME=vX.Y.0
export RELEASE_BRANCH_NAME="release-X.Y"
export RELEASE_CANDIDATE_NAME="$RELEASE_NAME-rc.1"

如果您要建立修補程式版本，請改用以下內容

export PREVIOUS_PATCH_RELEASE=vX.Y.Z
export RELEASE_NAME=vX.Y.Z+1
export RELEASE_BRANCH_NAME="release-X.Y"

設定簽署金鑰

我們還將透過雜湊二進制檔案並提供簽名檔案來新增版本控制流程的安全性與驗證。我們使用 GitHub 和 GPG 執行此操作。如果您尚未設定 GPG，可以按照以下步驟操作

擁有簽署金鑰後，您需要將其新增到儲存庫根目錄的 KEYS 檔案中。將其新增到 KEYS 檔案的說明位於檔案中。如果您尚未這樣做，則需要將您的公開金鑰新增到金鑰伺服器網路。如果您使用 GnuPG，您可以按照 Debian 提供的說明進行操作。

1. 建立發佈分支

主要/次要版本

主要版本適用於新增功能和 *破壞向後相容性* 的行為變更。次要版本適用於不破壞向後相容性的新功能新增。要建立主要或次要版本，請先從 main 建立 release-X.Y 分支。

git fetch upstream
git checkout upstream/main
git checkout -b $RELEASE_BRANCH_NAME

這個新分支將成為版本的基礎，我們稍後將對其進行迭代。

驗證 GitHub 上是否存在 helm/helm 里程碑（如有必要，請建立它）。確保此版本的 PR 和問題都在此里程碑中。

對於主要和次要版本，請繼續執行步驟 2：主要/次要版本：在 Git 中變更版本號。

修補程式版本

修補程式版本是對現有版本的一些關鍵挑選修復。首先建立 release-X.Y 分支

git fetch upstream
git checkout -b $RELEASE_BRANCH_NAME upstream/$RELEASE_BRANCH_NAME

從這裡，我們可以挑選我們想要帶入修補程式版本的提交。

# get the commits ids we want to cherry-pick
git log --oneline
# cherry-pick the commits starting from the oldest one, without including merge commits
git cherry-pick -x <commit-id>

挑選提交後，需要推送版本分支。

git push upstream $RELEASE_BRANCH_NAME

推送分支將導致測試運行。在建立標籤之前，請確保它們通過。這個新標籤將成為修補程式版本的基礎。

建立 helm/helm 里程碑對於修補程式版本是可選的。

請務必查看 CircleCI 上的 helm，以查看版本在繼續之前是否通過 CI。修補程式版本可以跳過步驟 2-5 並繼續執行步驟 6 以完成版本。

2. 主要/次要版本：在 Git 中變更版本號

執行主要或次要版本時，請務必使用新的版本號更新 internal/version/version.go。

$ git diff internal/version/version.go
diff --git a/internal/version/version.go b/internal/version/version.go
index 712aae64..c1ed191e 100644
--- a/internal/version/version.go
+++ b/internal/version/version.go
@@ -30,7 +30,7 @@ var (
        // Increment major number for new feature additions and behavioral changes.
        // Increment minor number for bug fixes and performance enhancements.
        // Increment patch number for critical fixes to existing releases.
-       version = "v3.3"
+       version = "v3.4"

        // metadata is extra build time data
        metadata = ""

除了更新 version.go 檔案中的版本之外，您還需要更新使用該版本號的相應測試。

cmd/helm/testdata/output/version.txt
cmd/helm/testdata/output/version-client.txt
cmd/helm/testdata/output/version-client-shorthand.txt
cmd/helm/testdata/output/version-short.txt
cmd/helm/testdata/output/version-template.txt
pkg/chartutil/capabilities_test.go

git add .
git commit -m "bump version to $RELEASE_NAME"

這將僅針對 $RELEASE_BRANCH_NAME 更新它。您還需要將此變更拉入主分支，以便在建立下一個版本時使用，如此 3.2 到 3.3 的範例所示，並將其新增到下一個版本的里程碑中。

# get the last commit id i.e. commit to bump the version
git log --format="%H" -n 1

# create new branch off main
git checkout main
git checkout -b bump-version-<release_version>

# cherry pick the commit using id from first command
git cherry-pick -x <commit-id>

# commit the change
git push origin bump-version-<release-version>

3. 主要/次要版本：提交並推送發佈分支

為了讓其他人開始測試，我們現在可以將版本分支推送到上游並開始測試流程。

git push upstream $RELEASE_BRANCH_NAME

請務必查看 CircleCI 上的 helm，以查看版本在繼續之前是否通過 CI。

如果有人在，請讓其他人繼續檢查分支之前進行同行評審，以確保已進行所有適當的變更，並且版本的所有提交都在那裡。

4. 主要/次要版本：建立候選版本

現在版本分支已準備就緒，是時候開始建立和迭代候選版本了。

git tag --sign --annotate "${RELEASE_CANDIDATE_NAME}" --message "Helm release ${RELEASE_CANDIDATE_NAME}"
git push upstream $RELEASE_CANDIDATE_NAME

CircleCI 將自動建立帶標籤的版本映像和用戶端二進制檔案以進行測試。

對於測試人員，在 CircleCI 完成構建工件後開始測試的流程涉及以下步驟以獲取用戶端

linux/amd64，使用 /bin/bash

wget https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-linux-amd64.tar.gz

darwin/amd64，使用 Terminal.app

wget https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-darwin-amd64.tar.gz

windows/amd64，使用 PowerShell

PS C:\> Invoke-WebRequest -Uri "https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-windows-amd64.tar.gz" -OutFile "helm-$ReleaseCandidateName-windows-amd64.tar.gz"

然後，解壓縮二進制檔案並將其移動到 $PATH 上的某個位置，或者將其移動到某個位置並將其新增到您的 $PATH（例如 linux/macOS 的 /usr/local/bin/helm，Windows 的 C:\Program Files\helm\helm.exe）。

5. 主要/次要版本：迭代 successive 候選版本

花費幾天時間明確投入時間和資源，嘗試以各種可能的方式破壞 helm，並記錄與版本相關的任何發現。這段時間應該花在測試和尋找版本可能導致各種功能或升級環境出現問題的方式上，而不是編碼。在此期間，版本處於程式碼凍結狀態，任何其他程式碼變更都將推遲到下一個版本。

在此階段，$RELEASE_BRANCH_NAME 分支將不斷發展，因為您將產生新的候選版本。新候選版本的頻率由版本管理員決定：根據報告問題的嚴重程度、測試人員的可用性和版本截止日期，運用您的最佳判斷。一般來說，最好讓版本超過截止日期，也不要發佈有問題的版本。

每次您想要產生一個新的候選版本時，您會先從 main 分支中挑選提交 (cherry-pick commits) 並添加到分支中。

git cherry-pick -x <commit_id>

您還需要將分支推送到 GitHub 並確保它通過持續整合 (CI)。

之後，標記它並通知用戶新的候選版本。

export RELEASE_CANDIDATE_NAME="$RELEASE_NAME-rc.2"
git tag --sign --annotate "${RELEASE_CANDIDATE_NAME}" --message "Helm release ${RELEASE_CANDIDATE_NAME}"
git push upstream $RELEASE_CANDIDATE_NAME

推送至 GitHub 後，檢查以確保帶有此標籤的分支在 CI 中構建成功。

從這裡開始，只需重複此過程，持續測試，直到您對候選版本滿意為止。對於候選版本，我們不會撰寫完整的說明，但您可以搭建一些發行說明的架構。

6. 完成發行版本

當您最終對候選版本的品質感到滿意時，您可以繼續創建正式版本。最後再檢查一次以確保一切正常，然後最終推送發行標籤。

git checkout $RELEASE_BRANCH_NAME
git tag --sign --annotate "${RELEASE_NAME}" --message "Helm release ${RELEASE_NAME}"
git push upstream $RELEASE_NAME

驗證發行版本是否在 CircleCI 中成功。如果沒有，您需要修復發行版本並再次推送發行標籤。

由於 CI 作業需要一些時間才能運行，您可以在等待它完成的同時繼續撰寫發行說明。

7. 撰寫發行說明

我們會根據發行週期內發生的提交自動生成變更日誌，但如果發行說明是由真人／行銷團隊／狗狗親自撰寫，通常對終端用戶更有益。

如果您要發行主要／次要版本，列出值得注意的使用者功能通常就足夠了。對於修補程式版本，請執行相同的操作，但請記下症狀和受影響的人。

發行說明應包含版本和下一個版本的計劃日期。

次要版本的發行說明範例如下：

## vX.Y.Z

Helm vX.Y.Z is a feature release. This release, we focused on <insert focal point>. Users are encouraged to upgrade for the best experience.

The community keeps growing, and we'd love to see you there!

- Join the discussion in [Kubernetes Slack](https://kubernetes.slack.com):
  - `#helm-users` for questions and just to hang out
  - `#helm-dev` for discussing PRs, code, and bugs
- Hang out at the Public Developer Call: Thursday, 9:30 Pacific via [Zoom](https://zoom.us/j/696660622)
- Test, debug, and contribute charts: [Artifact Hub helm charts](https://artifacthub.io/packages/search?kind=0)

## Notable Changes

- Kubernetes 1.16 is now supported including new manifest apiVersions
- Sprig was upgraded to 2.22

## Installation and Upgrading

Download Helm X.Y. The common platform binaries are here:

- [MacOS amd64](https://get.helm.sh/helm-vX.Y.Z-darwin-amd64.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-darwin-amd64.tar.gz.sha256sum) / CHECKSUM_VAL)
- [Linux amd64](https://get.helm.sh/helm-vX.Y.Z-linux-amd64.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-amd64.tar.gz.sha256sum) / CHECKSUM_VAL)
- [Linux arm](https://get.helm.sh/helm-vX.Y.Z-linux-arm.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-arm.tar.gz.sha256) / CHECKSUM_VAL)
- [Linux arm64](https://get.helm.sh/helm-vX.Y.Z-linux-arm64.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-arm64.tar.gz.sha256sum) / CHECKSUM_VAL)
- [Linux i386](https://get.helm.sh/helm-vX.Y.Z-linux-386.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-386.tar.gz.sha256) / CHECKSUM_VAL)
- [Linux ppc64le](https://get.helm.sh/helm-vX.Y.Z-linux-ppc64le.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-ppc64le.tar.gz.sha256sum) / CHECKSUM_VAL)
- [Linux s390x](https://get.helm.sh/helm-vX.Y.Z-linux-s390x.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-s390x.tar.gz.sha256sum) / CHECKSUM_VAL)
- [Windows amd64](https://get.helm.sh/helm-vX.Y.Z-windows-amd64.zip) ([checksum](https://get.helm.sh/helm-vX.Y.Z-windows-amd64.zip.sha256sum) / CHECKSUM_VAL)

The [Quickstart Guide](https://docs.helm.sh/using_helm/#quickstart-guide) will get you going from there. For **upgrade instructions** or detailed installation notes, check the [install guide](https://docs.helm.sh/using_helm/#installing-helm). You can also use a [script to install](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3) on any system with `bash`.

## What's Next

- vX.Y.Z+1 will contain only bug fixes and is planned for <insert DATE>.
- vX.Y+1.0 is the next feature release and is planned for <insert DATE>. This release will focus on ...

## Changelog

- chore(*): bump version to v2.7.0 08c1144f5eb3e3b636d9775617287cc26e53dba4 (Adam Reese)
- fix circle not building tags f4f932fabd197f7e6d608c8672b33a483b4b76fa (Matthew Fisher)

可以通過運行以下命令來創建包含變更日誌的不完整發行說明：

export VERSION="$RELEASE_NAME"
export PREVIOUS_RELEASE=vX.Y.Z
make clean
make fetch-dist
make release-notes

這將創建一套良好的發行說明基準，您只需要填寫「重要變更」和「下一步是什麼」部分。

請隨時在發行說明中加入您的個人風格；讓人們覺得我們不全是機器人，這感覺很好。

您還應仔細檢查自動生成的發行說明中的網址和校驗和是否正確。

完成後，前往 GitHub 的 helm/helm 發行版本並使用此處撰寫的說明編輯已標記發行版本的發行說明。對於目標分支，請設置為 $RELEASE_BRANCH_NAME。

在發佈發行版本之前，最好讓其他人看一下發行說明。發送請求到 #helm-dev 進行審查。這總是有益的，因為很容易遺漏一些東西。

8. 使用 PGP 簽署下載檔案

雖然雜湊值提供了下載內容與生成內容一致的簽名，但簽名包提供了包來源的可追溯性。

為此，請運行以下 make 命令：

export VERSION="$RELEASE_NAME"
make clean		# if not already run
make fetch-dist	# if not already run
make sign

這將為 CI 推送的每個檔案生成 ASCII 碼裝甲簽名檔案。

所有簽名檔案 (*.asc) 都需要上傳到 GitHub 上的發行版本（附加二進制檔案）。

9. 發佈發行版本

是時候正式發佈了！

在 GitHub 上儲存發行說明、CI 構建完成，並且您已將簽名檔案添加到發行版本後，您可以點擊發行版本上的「發佈」。這將發佈發行版本，將其列為「最新版本」，並在 helm/helm 儲存庫的首頁上顯示此發行版本。

10. 更新文件

Helm 網站文件部分列出了文件的 Helm 版本。需要在網站上更新主要、次要和修補程式版本。下一個次要版本的日期也會發佈在網站上，並且必須更新。為此，請針對 helm-www 儲存庫創建一個拉取請求。在 config.toml 檔案中找到適當的 params.versions 部分並更新 Helm 版本，例如更新當前版本的範例。在同一個 config.toml 檔案中，更新 params.nextversion 部分。

關閉發行版本的 helm/helm 里程碑（如果適用）。

更新主要和次要版本的版本偏差。

更新發佈日曆這裡

為下一個次要版本創建一個條目，並在格林威治標準時間下午 5 點設置提醒。
在下一個次要版本計劃發佈前一周的星期一為其 RC1 創建一個條目，並在格林威治標準時間下午 5 點設置提醒。

11. 告訴社群

恭喜！您完成了。去喝一杯 $DRINK_OF_CHOICE 吧。這是您應得的。

享受完一杯美味的 $DRINK_OF_CHOICE 後，繼續在 Slack 和 Twitter 上宣布新版本，並附上 GitHub 上發行版本的鏈接。

（可選）撰寫一篇關於新版本的部落格文章，並在其中展示一些新功能！