制作发布#

发布是维护者告知世界——或者更准确地说，下游开发者——更新其依赖项的时候。这些指南解释了维护者如何生成这些发布。

设置 GitLab CI/CD 管道和一个签名密钥#

如果您的项目尚未拥有发布 CI 管道，您需要 创建一个。

如果您尚未设置用于签名发布的 GPG 密钥，您需要 设置一个。

标记发布之前#

以下步骤通常在将要发布的的分支上完成。但是，如果您的项目配置为不允许推送到此分支，则需要在稍后合并的单独分支上进行。

  • 确保项目正在构建并通过测试。

  • 如果需要，更新版本号（在 meson.build 或等效文件中）。

  • 对于一个库，如果库的版本控制不是从项目版本自动计算得出的，请更新库的版本控制。库的版本控制传递给 Meson 的 library 方法 的 soversion 和 version 参数。库的版本控制代表库的 API 级别，通常与项目版本分开。

  • 如果需要，更新 README。

  • 如果模块是一个应用程序，请在 AppStream 元数据文件中添加一个 <release> 条目（请参阅 AppStream 文档）。

    • 可选地，阅读 Git 提交日志，并为每个重要的更改提出一个要点，并感谢完成这项工作的人员。请记住，AppStream 元数据由 GUI 工具呈现给用户。一些技巧

      • 尽量使要点简短明了，但也要让普通用户能够理解（并不总是容易）。

      • 如果多个条目与相同的更改相关，则仅使用一个要点。

  • AppStream 规范不处理版本中的字母组件，因此在发布开发快照（alpha、beta 或 rc）时，您需要使用波浪号作为 release 元素中 version 属性的分隔符，例如 43.alpha 变为 43~alpha；44.beta 变为 44~beta；45.rc 变为 45~rc。

    • 您还可以选择不在 AppStream 元数据中列出开发快照，而是在第一个稳定版本中制作完整的发布描述。

  • 更新 NEWS 文件

    • NEWS 文件通常由打包者和集成者使用，因此您可以比在 AppStream 元数据中更详细。

    • 可选地，您可以使用 此脚本 从您的 Git 历史记录生成 NEWS 文件。

    • 您可能希望提及更新的依赖项，因为这可以方便打包者。

    • 您可以使用类似以下格式

Version 43.0
------------
* Dependency update
* Some change
* A bug fix
* Small maintenance tasks
* Translation updates

  • 使用 git commit --gpg-sign 提交这些更改。

    • 为每个版本签名提交允许验证该发布。有关设置提交签名的信息，请参阅 签名发布。

  • 推送您的更改。或者，如果您正在开发分支上工作，请将其合并到将要发布的分支。

标记作为发布信号#

通过将带批注的标签推送到 GitLab 仓库来触发发布自动化。标签应根据发布版本号命名。

以下通常在将要发布的分支上完成。创建一个带批注的标签

  1. 最好的方法是 git evtag sign <tag>，使用 git-evtag。这提供了强大的签名保证。

  2. 如果您无法做到这一点，请以基本方式进行：git tag -s <tag>。

  3. 或者，更糟：git tag -a <tag>。

这将启动一个编辑器，让您输入要用于标签的消息。写下项目名称和版本

GNOME Foo 43.0

创建标签后，使用 git push origin <tag> 将其推送到 GitLab 仓库。管道将被触发，发布过程将开始。

监控发布#

在 GitLab 仓库中创建标签时，发布过程将自动开始。作业将生成 tarball 并将其上传到 GNOME 服务器。您可以从 GitLab 界面监控发布。

作业完成后，通过检查它是否列在 download.gnome.org/sources 和模块的 GitLab 项目的发布下，来验证发布是否成功。