发布 PLC4X

快速摘要

我们已经把项目 tools 目录中的大部分步骤和检查工作实现了自动化。唯一的前提条件通常是安装 Docker，因为我们使用 reference machine 来确保构建的可重现性。

定期地，尤其是在启动发布流程之前，请运行：

• release-0-update-generated-code.sh：删除所有生成的代码并重新生成（清除不再有效的类型），刷新生成的驱动文档并更新 NOTICE 文件中的年份。

启动发布流程时，创建发布分支：

• release-1-create-branch.sh：完成当前发布版本的 RELEASE_NOTES 并为下一个版本新增章节，检查 git 是否已正确配置，然后在启用所有模块的情况下，通过 Docker 运行创建分支的构建。

通常接下来会有一段代码稳定期。当该阶段结束，或者我们不进行这样的稳定阶段时，就着手准备实际的发布。

• release-2-prepare-release.sh：在 Docker 内部使用 maven 执行实际的发布流程。对本地暂存的构件进行签名，将其部署到 Nexus 并在 SVN 中进行暂存。它还会检查当前 RM 的 GPG 密钥以及 SHA512 是否已包含在 KEYS 文件中。最后一步，它会起草一封包含所有必要信息的邮件，用于发起投票。

准备你的系统以便能够发布

作为发布流程的一部分，Maven 会将 maven 发布构件上传到所谓的暂存仓库。

可以把它想象成一个临时的 Maven 仓库，其中只包含某一次发布的构件。这有助于评审人员查看便捷的 maven 包中包含的内容，并一键将其发布到公共仓库。

为了获准上传构件，你的账户必须启用该功能，并且需要将你的凭据告知 Maven。

为此，你应该通过 .m2/settings.xml 提供这些凭据。

因此，如果你还没有相应的文件，应该在用户主目录下创建一个 .m2 目录，并在其中创建一个 settings.xml 文件，至少包含如下内容：

<?xml version="1.0" encoding="UTF-8"?>
<settings xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0 http://maven.apache.org/xsd/settings-1.1.0.xsd" xmlns="http://maven.apache.org/SETTINGS/1.1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <servers>
    <!-- Apache Repo Settings -->
    <server>
        <id>apache.snapshots.https</id>
        <username>{user-id}</username>
        <password>{user-pass}</password>
    </server>
    <server>
        <id>apache.releases.https</id>
        <username>{user-id}</username>
        <password>{user-pass}</password>
    </server>
  </servers>
</settings>

这会告诉 Maven，在使用 id 为 apache.snapshots.https 或 apache.releases.https 的仓库时使用上述凭据。发布时你只需要 releases 仓库，但保留另一个仓库也很有用，因为它可以让你从本机部署 SNAPSHOT 版本。这些仓库在 apache 父 POM 中定义，对所有 Apache 项目而言都是相同的。

此外，发布构建会自动对所有构件进行签名。为了能够这样做，你需要配置 GPG。

用于签名构件的密钥必须与你的 Apache 邮箱（{apache-id}@apache.org）关联，并且至少由一位拥有可信密钥的 Apache 提交者（理想情况下更多）验证。通常，你需要在线下与任何持有可信密钥的 Apache 提交者取得联系来完成此事。参加 ApacheCon 通常是实现这一点的好办法，因为每届 ApacheCon 的日程中通常都会安排 Key Signing event。他可以为你的密钥签名，从而使你能够为 Apache 发布的构件签名。

详细的说明请参见 此处。

如果你拥有多个密钥，将以下 profile 添加到你的 settings.xml 中应该会有帮助：

<profile>
  <id>apache-release</id>
  <properties>
    <gpg.keyname>5C60D6B9</gpg.keyname><!-- Your GPG Keyname here -->
    <!-- Use an agent: Prevents being asked for the password during the build -->
    <gpg.useagent>true</gpg.useagent>
    <gpg.passphrase>topsecret-password</gpg.passphrase>
  </properties>
</profile>

目前，能够发布所有模块的 Java 版本最佳选择是 Java 11。

因此，请务必把 Java 11 设置为用于执行发布的 Java 版本。

此外，CMake 至少需要 Maven 3.6。

理想情况下，请使用 Maven Wrapper（Maven 包装器）以确保 Maven 版本与构建相匹配。

在某些系统（主要是 Mac）上，gpg 签名可能会导致如下错误：

[INFO] --- maven-gpg-plugin:3.0.1:sign (sign-release-artifacts) @ plc4x-parent ---
gpg: signing failed: Inappropriate ioctl for device

这种情况下，加入以下内容会有所帮助：export GPG_TTY=$(tty)

发布脚本

从这里开始，发布流程由项目 tools 目录中带编号的脚本来驱动。这些脚本需要按顺序执行，每个脚本在结束时都会打印出接下来要运行的脚本。

| 脚本 | 覆盖内容 |

|
|--------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| release-0-update-generated-code.sh | 丢弃并重新生成所有生成的代码，刷新驱动文档以及 NOTICE 年份。 |
| release-1-create-branch.sh | 完成 RELEASE_NOTES，创建 rel/<major>.<minor> 分支，并将 develop 推进到下一个次版本。 |
| release-2-prepare-release.sh | 为发布打标签并构建，对制品进行签名并暂存到 Nexus 和 SVN 中，同时起草 [VOTE] 和 [DISCUSS] 邮件。 |
| release-3-finish-release.sh | 投票成功后的所有操作：将发布分支的文档发布为当前版本，把该分支加入网站构建，将发布记录到 DOAP 文件以及两个分支的下载页面中，起草 [RESULT] 和 [ANNOUNCE] 邮件，把发布候选版本移至 SVN 的发布区域，释放 Nexus 暂存仓库，并清理未能成功发布的尝试以及它所取代的版本。参见投票成功之后。 |
| release-abort.sh | 帮助撤销一次失败的尝试。 |
| validate-release.sh | 验证暂存的发布候选版本能够可重复构建。主要供参与投票的人员使用。 |

这些脚本运行的所有 Maven 构建都在 tools/docker-compose.yaml 所描述的 Docker 容器内进行，该容器将项目绑定挂载到 /ws，并使用 out/.repository 作为其本地 Maven 仓库。正是这一点保证了构建的可复现性，也是构建结果不依赖于你机器上安装了什么的原因。

请注意，release-2-prepare-release.sh 中的签名以及所有 git 和 svn 操作都在你的机器上运行，而不是在容器内。因此，GPG、你的 git 凭据以及你的 Apache SVN 凭据都必须在宿主机上可用。

为发布准备代码库

在开发过程中定期执行此操作，并且务必在开始发布之前执行：

./tools/release-0-update-generated-code.sh

它执行以下步骤：

1. 删除 out 目录，该目录存放 Maven 本地仓库以及先前部署的构件。
2. 删除所有生成的代码，然后通过启用全部 profile 与 update-generated-code 运行完整构建来重新生成代码。这正是脚本的关键所在：否则，代码生成不再产生的类型会残留下来，并悄然进入发布内容。与生成文件存放在一起的手写文件会被保留（StaticHelper.go、StaticHelper_test.go、StaticHelper.py、init.py）。
3. 将 NOTICE 文件的第二行设置为 Copyright 2017-<current year> The Apache Software Foundation，以完成每年一次的更新。
4. 运行 mvn site -pl :plc4j-driver-all 重新生成驱动文档。
5. 将所有变更以 chore: updated generated code 提交并推送。

步骤 2 中的构建跳过了测试，因此脚本运行成功只能说明项目仍然可以编译和生成代码，而不能说明它仍然能正常工作。

更新 RELEASE_NOTES

这部分不是自动化的，必须在创建分支之前完成，否则事后你需要将它移植回 develop。

填写你即将发布版本对应的章节：查看自上次发布以来合并的内容，并补全 New Features、Incompatible changes 和 Bug Fixes 各个板块。

你不必修改 (Unreleased) Apache PLC4X <version>-SNAPSHOT 标题，也不必为下一个版本添加章节——release-1-create-branch.sh 两者都会完成。

创建发布分支

根据 SemVer，我们有 Major（主版本）、Minor（次版本）和 Bugfix（缺陷修复）三种发布。对于每个新的 Major 和 Minor 发布，我们会在代码冻结阶段开始时创建一个分支，这也是 develop 上版本号递增的时刻。

./tools/release-1-create-branch.sh

脚本从当前项目版本中推导出所需的全部版本信息，因此除了确认之外无需输入任何内容。对于位于 1.0.0-SNAPSHOT 的 develop，结果如下：

随后脚本会：

1. 询问 Have the RELEASE_NOTES been updated for this version?。输入除 yes 之外的任何内容都会中止。

2. 将 RELEASE_NOTES 中的 (Unreleased) Apache PLC4X 1.0.0-SNAPSHOT 标头改写为 Apache PLC4X 1.0.0，并提交该更改。

3. 检查 git 中是否已配置 user.name 和 user.email，若未配置则打印用于修复的命令。提交是在容器内创建的，因此需要显式传入这些值。

4. 在容器内以 -DpushChanges=false 运行 mvn release:branch，并启用所有配置文件。

   	启用所有配置文件正是使插件同时更新非默认模块版本的原因。否则，develop 上的这些模块会继续引用旧版本，导致构建失败。

5. 在 RELEASE_NOTES 开头插入一个全新的 (Unreleased) Apache PLC4X 1.1.0-SNAPSHOT 部分，并提交它。

6. 推送 develop，检出 rel/1.0，并使用 --set-upstream 推送它。

完成后，你的本地检出将位于发布分支上，而 develop 已进入下一个次版本。

之后，对旧版本执行一次快速全文搜索，确认所有地方都已更新。

文档版本的维护方式

这里你无需做任何操作——release-1-create-branch.sh 会负责处理——但值得了解其原理，因为它决定了网站将哪个版本作为当前版本提供。

每个分支都在自身的 website/asciidoc/antora.yml 中指明其所记录的具体版本，并标记该版本是否已发布：

不过，发布分支最初并不是这个样子。release-1-create-branch.sh 创建它时使用的是 prerelease: True，因为此时还没有进行任何投票。

在代码冻结和投票进行期间，一切都不会被发布：Antora 只读取 website/antora-playbook.yml 中 content.sources 列出的分支，而新分支只有在投票结束后才由 release-3-finish-release.sh 添加进去。因此，/plc4x/latest/ 在整个过程中始终提供上一个版本。

prerelease 这一标志在分支被添加时至关重要。Antora 在选择最新版本时会跳过预发布版本，因此，如果在仍带有该标志时添加分支，它会以自己的版本号出现，而不会接管 /plc4x/latest/。release-3-finish-release.sh 会在同一次运行中添加分支并清除该标志，正是这一操作将新发布版本提升为 /plc4x/latest/，并把上一个版本移回其自身的版本号下。

没有分支会自行命名为 latest 或 pre-release，这两段内容反而来自剧本（playbook）：

urls:
  latest_version_segment: latest
  latest_prerelease_version_segment: pre-release

Antora 通过版本号排序挑选组件的最新版本，并在这一过程中跳过预发布版本，然后将该版本发布在符号化路径段下。因此，develop 永远不会变成 latest，而创建更新的发布分支会把之前的分支降为其自身的版本号，该旧分支上的任何内容都无需改动。

release-1-create-branch.sh 将 develop 推进到下一个版本，并把新的发布分支设置为它即将发布的版本，两者仍标记为预发布版本。release-3-finish-release.sh 从 release-2-prepare-release.sh 创建的标签中取得版本号并清除预发布标记，因此它对缺陷修复版本也能做出正确的处理，此时 release-1-create-branch.sh 从未执行。

同一文件中更下方的两个 current-*-version 属性由构建过程保持同步，同样不应手工编辑。

发布稳定阶段

接下来通常会进入执行最后测试和检查的阶段。

如果发现问题，必须在发布分支中修复。

更改应当重新应用到 develop 或 cherry-picked 中。把更改合并回来会引发大量问题，因为这些分支不再共享相同的版本。

准备并暂存发布候选版本

特别是在频繁切换不同分支的情况下，建议对仓库进行一次干净的检出。否则可能会残留大量目录，而这些目录会被包含进源码发布 zip 包中。

确认你位于发布分支上，然后运行：

./tools/release-2-prepare-release.sh

这是最长的一步——它把发布流程从打了标签的提交一路推进到暂存的发布候选版本，并起草投票邮件。它唯一需要你提供的，是发布候选版本编号。

在执行任何操作之前，它会先推导出发布版本（1.0.0）、标签名称（v1.0.0）以及下一个开发版本（1.0.1-SNAPSHOT——注意这是补丁级别的版本递增，与 release-1 中的情况不同），如果该标签已经存在于本地或 origin 上，它会拒绝继续，并明确告诉你该如何删除它。这通常是上一次尝试失败后留下的结果。

接着它会依次执行以下步骤：

1. 在容器中运行 mvn release:prepare，启用全部 profile，并显式传入版本号和标签，这样插件就不会提出任何问题。这一步会检查是否引用了任何 SNAPSHOT 依赖，更新所有 pom，运行包含测试的完整构建，然后提交、打标签并准备好下一个开发版本。

2. 推送结果，并记录该标签所指向的提交哈希，供投票邮件使用。

3. 在容器中运行 mvn release:perform，将其部署到 out/.local-artifacts-dir，而不是直接发布到 Nexus。此时还没有任何内容离开你的机器。

4. 使用 gpg -ab 对该目录中的每一个构件进行签名——pom、jar、kar、nar、feature 与 site 描述文件、CycloneDX SBOM 以及源码发布 zip。这一步在宿主机上运行，使用你的 GPG 配置。

5. 使用 nexus-staging:deploy-staged-repository 将签名后的仓库上传到 Nexus 并将其关闭，然后打印出已关闭的暂存仓库的 URL。

   	如果这里因为 404 而失败，说明脚本中硬编码的暂存 profile id 已经过时。登录 https://repository.apache.org，打开 Staging Profiles，选择 org.apache.plc4x，然后从浏览器 URL 中 #stagingProfiles; 之后的部分取出该 id。

6. 询问发布候选版本编号，并组装 out/stage/<version>/rc<n>/，其中包含 README、RELEASE_NOTES、附带其 .asc 和 .sha512 的源码发布 zip，以及附带其签名的 CycloneDX SBOM。

7. 下载官方 KEYS 文件，将其导入一个一次性的密钥环，据此验证签名，并检查签名所用的密钥带有 apache.org 地址。

   	这些检查正是用来发现初次担任发布经理时那些典型错误的。如果第一项失败，说明你的密钥还不在 KEYS 文件中——按照该文件本身记录的格式把它添加进去即可。如果第二项失败，说明你是用一个未注册到你 {apache-id}@apache.org 地址的密钥签名的；脚本会打印出该密钥所带的用户 id。一个密钥可以有多个用户 id，其中只要有一个是 Apache 的即可。

8. 重新计算源码发布 zip 的 SHA-512，并与 .sha512 文件进行比对。

9. 使用 svn import 将发布候选版本目录导入 Apache dev SVN，从而得到投票邮件中引用的目录结构：

      https://dist.apache.org/repos/dist/dev/plc4x/1.0.0/rc1/README
      https://dist.apache.org/repos/dist/dev/plc4x/1.0.0/rc1/RELEASE_NOTES
      https://dist.apache.org/repos/dist/dev/plc4x/1.0.0/rc1/apache-plc4x-1.0.0-source-release.zip
      https://dist.apache.org/repos/dist/dev/plc4x/1.0.0/rc1/apache-plc4x-1.0.0-source-release.zip.asc
      https://dist.apache.org/repos/dist/dev/plc4x/1.0.0/rc1/apache-plc4x-1.0.0-source-release.zip.sha512

10. 写出 out/stage/vote-email.eml 和 out/stage/discuss-email.eml，其中已经填入了发布版本号、RC 编号、标签提交哈希、暂存仓库 URL 和 SVN URL。

验证 git 历史

尽管现在已脚本化，仍值得检查仓库 https://gitbox.apache.org/repos/asf?p=plc4x.git](https://gitbox.apache.org/repos/asf?p=plc4x.git) 是否处于正确状态。切换到发布分支，并确认提交历史如下所示：

提交信息为 [maven-release-plugin] prepare release v1.0.0 的提交必须带有发布标签，并且只应包含版本号更新。紧随其后的是一个 [maven-release-plugin] prepare for next development iteration 提交，它将分支推进到下一个缺陷修复版本。

在邮件列表上发起投票

两封邮件已在 out/stage/ 中为你起草。先通读一遍，然后发送它们——将 vote-email.eml 发出的 [VOTE] 邮件和 discuss-email.eml 发出的 [DISCUSS] 邮件，都发送到 dev@plc4x.apache.org。

之所以需要第二封邮件，是因为如果投票和讨论在同一个邮件线程中进行，计票会变得困难。

现在我们必须等待 72 小时才能公布结果。这是 Apache 的规定，目的是让所有人无论身处何地、无论当时正值哪个周末或公众假日，都能参与。

如果收到至少 3 票有效的 +1 投票，并且 +1 多于 -1，投票即告通过。

72 小时结束且满足该条件后，通过回复投票线程并以 [RESULT] 为前缀来结束投票。release-3-finish-release.sh 会为你起草这封邮件——它会询问两个票数，并在发布任何内容之前写出 out/stage/result-email.eml，因此即使你在确认步骤处停止脚本，也能收到这封邮件。

验证发布候选版本

任何参与投票的人都可以检查暂存的构件是否确实能从暂存的源码中重现：

./tools/validate-release.sh

它在同一个容器中构建项目，然后使用 artifact:compare 对暂存仓库中的结果进行逐字节比较。

请在解包后的 apache-plc4x-<version>-source-release.zip 中运行它，或者检出发布标签后运行——它拒绝在 SNAPSHOT 版本上运行，因为将开发版构建与发布仓库进行比较，对候选发布版本毫无意义。只有 Java 制品会被比较；C、.Net 和 Python 的制品要么与平台相关，要么根本没有发布到 Maven。

投票者需要检查的完整清单记录在 validating a release 页面上。

如果出了问题怎么办？

tools/release-abort.sh 可以帮助撤销一次尝试：

1. 将所有模块的版本恢复为开发版本。具体是哪个版本无法自动推导——release:branch 之后 pom 文件中是下一个次版本号，release:prepare 之后是下一个缺陷修复版本号——因此请将其作为参数传入，或者在提示时输入：

      ./tools/release-abort.sh 1.0.0-SNAPSHOT

2. 删除遗留的 release.properties、pom.xml.versionsBackup 和 pom.xml.releaseBackup 文件。

3. 提供删除发布标签和发布分支的选项，本地和远程各一次，分别询问每一项，并跳过不存在的项。

回退以生成新的候选发布版本

如果投票未通过，需要生成新的 RC：

1. 运行 tools/release-abort.sh 以重置版本并清理遗留文件。

2. 在本地和远程删除标签：

      git tag -d v1.0.0
      git push --delete origin v1.0.0

3. 提交并推送版本变更。

4. 在 https://repository.apache.org 处丢弃暂存仓库。

5. 从 SVN 中移除上一个 RC：

      svn rm https://dist.apache.org/repos/dist/dev/plc4x/1.0.0/rc1 -m"Removed rc1 of PLC4X 1.0.0"

6. 回复 VOTE 和 DISCUSS 邮件列表，说明投票已取消、解释原因并告知将有新的 RC。主题前加上 [CANCELLED] 前缀。

完成这些之后，你就可以再次运行 release-2-prepare-release.sh，并给它下一个 RC 编号。

投票成功之后

tools/release-3-finish-release.sh 涵盖了这一部分。

请在发布分支上运行它——投票通过后运行——它拒绝在其他任何地方运行，因为它所做的一切都会写入该分支。

它会先请求确认，然后从发布标签中获取已发布的版本，并完成五项操作：

1. 在发布分支上：将 Antora 描述符指向该版本，并清除 prerelease 标志，这会把新发布作为 /plc4x/latest/ 发布出去，同时把该发布添加到该分支的下载页面。
2. 在 develop 上：把发布分支添加到 website/antora-playbook.yml 中的 content.sources 列表里，正是这一步才让 Antora 真正去读取该分支。
3. 在 develop 上：把已发布的版本加入 website/resources/plc4x-doap.rdf，置于列表顶部并命名为 Latest，原先拥有该称号的条目降级为 Legacy，同时把该发布添加到 `develop 的下载页面副本中。发布日期即脚本运行的当天。
4. 将 [RESULT] 和 [ANNOUNCE] 邮件草拟到 out/stage/ 中，方式与 release-2-prepare-release.sh 草拟 [VOTE] 和 [DISCUSS] 邮件相同。不会有任何内容被发出——由你阅读后自行发送。
5. 发布构件并清理先前尝试遗留下来的内容——参见发布构件。这一步需要二次确认，因为它无法撤销。

对 develop 的两处改动是在一个临时工作树中完成并直接推送过去的，因此你的检出仍停留在发布分支上——之后你本地的 develop 会落后一个提交。

如果文档相关步骤已经完成则会被跳过，所以在脚本开始发布之前，重新运行脚本是无害的——而那部分会先询问你。

发布构件

release-3-finish-release.sh 负责执行这一步，而这是不归路——两部分都无法撤销，因此它在继续之前会再询问一次，并准确展示它即将执行的操作。

它通过取 https://dist.apache.org/repos/dist/dev/plc4x/ 下仍在暂存区中编号最大的 rc 来确定要发布哪个发布候选，然后：

1. 把该发布候选移动到 https://dist.apache.org/repos/dist/release/plc4x/，正是这一步开始把构件复制到镜像。这就是为什么你必须等待至少 24 小时才能发布公告。
2. 用 nexus-staging:rc-release 发布 Nexus 暂存仓库，把 Maven 构件移入 Apache 发布仓库，再由那里同步到 Maven Central。

暂存仓库的 id 从 out/.local-artifacts-dir 中留下的文件 release-2-prepare-release.sh 读取。该目录不会在 release-0-update-generated-code.sh 之后保留下来，如果你在另一台机器上完成发布，它根本不存在——此时脚本会询问该 id：它是 VOTE 邮件中 [1] 里 URL 的最后一段，例如 orgapacheplc4x-1234。

如果该版本已经发布，SVN 移动会被跳过。Nexus 没有同样廉价的查询方式，所以如果发布已出现在 SVN 中，脚本会假定暂存仓库也一并发布，并在再次尝试前先询问——这也是从移动成功但 Nexus 发布未成功的那次运行中恢复的方法。

事后清理

只有胜出的发布候选被移动了，必须重新投票的表决会在每次尝试后留下一个已关闭的暂存仓库，而 Apache 的政策是镜像只承载当前发布。脚本会提出清理这三者，并在删除任何内容之前先询问：

1. 它会列出 https://dist.apache.org/repos/dist/dev/plc4x/1.0.0/ 下剩余的内容，并询问是否删除整个目录。
2. 它会列出仍位于 https://dist.apache.org/repos/dist/release/plc4x/ 下的旧版本，并询问是否删除它们。只有看起来像版本号的目录才会被考虑 —— KEYS、build-tools 和 plc4x-extras 位于同一位置，不会被触碰。
3. 它会运行 nexus-staging:rc-list 并打印出已存在的暂存仓库，然后询问要丢弃哪些 id。Nexus 没有提供任何我们可以可靠依赖的信息来判断某个仓库属于哪一次尝试，因此这一步留作人工决定而不做猜测 —— 留空即可全部保留。

删除旧版本并不会使其不可用：它仍然保留在 https://archive.apache.org/dist/plc4x/ 上，而 https://downloads.apache.org 对于它不再保留的任何内容都会重定向到那里，因此下载页面上的链接始终有效。

更新网站

release-3-finish-release.sh 会完成上述所有操作。不过旧版本不会自动从 Antora playbook 中移除 —— 你需要自行决定网站应当继续构建多少个文档版本。这与镜像是两回事，镜像始终只承载当前发布版本。

下载页面值得一提，因为每个发布文档的分支都会有各自的一份，而且每一份都必须列出该发布：/plc4x/latest/users/download.html 由发布分支提供，/plc4x/pre-release/…​ 则来自 develop。脚本会以完全相同的方式更新这两份。

对于每一份，它会把原先的当前条目下移到 Previous Releases，将其源发布链接指向归档地址，并把新发布置于 Current Releases 顶部，同时为目录添加锚点。发布说明取自发布分支的 RELEASE_NOTES，并转换为 AsciiDoc。

合并回 release 分支

release 分支应当始终指向最后一次发布的版本：

git checkout release
git merge -X theirs v1.0.0

theirs 策略能解决大多数冲突，但有时仍需手动解决。之后请推送。

更新 GitHub Issue

1. 将已发布版本设为「released」，并设置「release-date」。
2. 将下一个版本添加到 versions 中。

通知全世界

在将发布候选版本移动到 SVN 的发布部分之后，请至少等待 24 小时，以确保 Apache 镜像站有足够时间获取发布文件。

release-3-finish-release.sh 已经起草了发往 out/stage/announce-email.eml 的公告，收件人为 announce@apache.org，并抄送 dev@plc4x.apache.org。

需要注意的是，你必须使用你的 Apache 邮箱地址发送这封邮件，否则邮件会被拒收。对我来说，配置这一点并不简单。总体说明可以参见：https://reference.apache.org/committer/email 以下是我为在 Google Mail 中允许发送邮件所做的设置：https://gmail.googleblog.com/2009/07/send-mail-from-another-address-without.html 注意……​如果你点击新邮件的收件人栏，就可以选择备用发送地址（这并不直观）。