发布清单

维护者发布舵的指南

发布新舵版本的时间到了！作为发布舵版本的维护者，您是更新此发布清单的最佳人选，如果您的经验与这里记录的不同。

所有版本都将采用 vX.Y.Z 的形式，其中 X 是主版本号，Y 是次版本号，Z 是补丁版本号。该项目严格遵循语义版本控制，因此遵循此步骤至关重要。

舵会提前宣布下一个次版本发布的日期。应尽一切努力尊重宣布的日期。此外，在开始发布流程时，应选择下一个版本的日期，因为它将在发布流程中使用。

这些说明将涵盖初始配置，然后是三种不同类型的发布的发布流程

主要版本 - 发布频率较低 - 有重大更改
次版本 - 每 3 到 4 个月发布一次 - 没有重大更改
补丁版本 - 每月发布一次 - 不需要本指南中的所有步骤

初始配置

创建发布分支
主要/次版本：更改 Git 中的版本号
主要/次版本：提交并推送发布分支
主要/次版本：创建发布候选版本
主要/次版本：迭代后续发布候选版本
完成发布
撰写发布说明
使用 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 文件中。添加它的说明在该文件中。如果您还没有这样做，您需要将您的公钥添加到密钥服务器网络。如果您使用 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 中的版本号.

补丁版本

补丁版本是对现有版本进行的一些关键的 cherry-pick 修复。请从创建 release-X.Y 分支开始：

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

从这里开始，我们可以 cherry-pick 我们想要引入补丁版本的提交：

# 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>

cherry-pick 完提交后，需要推送发布分支。

git push upstream $RELEASE_BRANCH_NAME

推送分支将导致测试运行。在创建标签之前，请确保测试通过。此新标签将作为补丁版本的基础。

创建 helm/helm 里程碑对于补丁版本是可选的。

请务必查看 CircleCI 上的舵，以确保发布通过 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。您还需要将此更改拉取到 main 分支，以便在创建下一个版本时使用，例如 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. 主要/次版本：提交并推送发布分支

为了让其他人开始测试，我们现在可以将发布分支推送到 upstream 并开始测试流程。

git push upstream $RELEASE_BRANCH_NAME

请务必查看 CircleCI 上的舵，以确保发布通过 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. 主要/次版本：迭代后续发布候选版本

花几天时间明确投入时间和资源，尽一切努力尽可能地破坏舵，并记录所有与发布相关的发现。这段时间应该花在测试和寻找发布可能导致各种功能或升级环境出现问题的方法上，而不是编码。在此期间，发布处于代码冻结状态，任何其他代码更改都将推迟到下一个版本。

在此阶段，$RELEASE_BRANCH_NAME 分支将不断发展，因为您将生成新的发布候选版本。新候选版本的频率由发布经理决定：请根据您对报告问题的严重程度、测试人员的可用性和发布截止日期的最佳判断做出决定。一般来说，让版本延期比发布一个有问题的版本要好。

每次您想要生成新的发布候选版本时，您将首先通过从 main cherry-pick 提交来向分支添加提交：

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

这将创建一个良好的发布说明基线集，您只需要填写**重大更改**和**下一步**部分。

随意在发布说明中添加您的声音；让人们觉得我们不是机器人是件好事。

您还应仔细检查自动生成的发布说明中的 URL 和校验和是否正确。

完成后，进入 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 上的发布的链接。

可选地，撰写一篇关于新发布的博文，并在其中展示一些新功能！