您正在阅读的是旧版本但仍受支持的 ROS 2 文档。 Jazzy.

ROS 2 软件包维护指南

ROS 2 核心软件中的每个软件包都有一个或多个维护者，他们负责软件包的整体健康。本指南介绍了 ROS 2 核心软件包维护者的一些职责。

评论 

所有进入 ROS 2 核心库的代码都必须经过审核。审核的内容包括

包装的适用性
正确代码
符合开发商的指导方针：
- 开发人员指南
- 代码风格指南
为错误/功能添加测试
为新功能添加文档
清洁的持续集成运行
目标为默认分支（通常为 "滚动 "分支）
至少有一次获得非作者的维护者的批准

持续集成 

所有进入 ROS 2 核心仓库的代码都必须通过持续集成（Continuous Integration）。ROS 2 目前有两个独立的 CI 系统，要求 PR 在合并前通过这两个系统。

PR 构建 (https://build.ros2.org/view/Rpr)

每次打开拉取请求时，ROS 2 PR（拉取请求）构建都会自动运行。这些编译只对该软件包进行编译和测试。这意味着它不会构建任何依赖包，也不会构建任何依赖于此软件包的软件包。这些联编很适合用于快速反馈，以查看变更是否通过了联编、单元测试等。它们有两个主要问题：

这些构建功能无法在多个版本库中使用（因此无法用于添加或更改应用程序接口等）。
这些测试只能在 Linux 上运行（不能在 MacOS 或 Windows 上运行）

为了解决这两个问题，还需要进行 CI 构建。

CI 构建 (https://ci.ros2.org)

拉取请求打开后，CI 构建不会自动运行。软件包的维护者之一必须通过访问 https://ci.ros2.org/job/ci_launcher/ .

默认情况下，以这种方式运行作业将在所有平台（Linux、macOS 和 Windows）上构建和运行所有软件包（目前为 300 个）的测试。由于一次完整的运行可能会耗费数小时并占用 CI 机器，因此建议所有运行都限制构建和测试的软件包数量。这可以通过使用 colcon 参数来实现 --包至, --软件包--选择, --packages-above and-dependencies, --上述软件包等等。参见 Colcon 文档以获取更多可使用标记的示例。有关如何使用 CI 机器的更多文档，请访问 https://github.com/ros2/ci/blob/master/CI_BUILDERS.md.

合并拉取请求 

如果以下条件全部为真，则可以合并拉取请求：

DCO 机器人报告结果合格
PR 构建报告结果合格
CI 构建在所有平台上都报告了通过结果
代码已由至少一名维护者审查和批准

合并 PR 后，它将自动与下一个夜报.强烈建议在合并拉取请求后检查夜校，以确保没有发生任何回归。

保持绿色 CI 

运行测试的夜间工作通常比针对单个拉取请求所做的工作要全面得多。因此，在夜间工作中可能会出现 CI 工作中未发现的回归。软件包维护者有责任在以下位置检查其软件包中的回归情况：

对于发现的任何问题，应在相关资源库中开启新问题和/或拉动请求。

进行发布 

为了向最终用户提供新功能和错误修正，软件包维护者必须定期发布软件包（也可根据需要向其他维护者请求发布）。

正如开发人员指南，ROS 2 软件包的版本号遵循 semver。

用 ROS 术语来说，发布包括两个不同的步骤：发布源代码，然后发布二进制版本。

来源发布 

源代码发布会在相关版本库中创建更新日志和标签。

首先，使用以下命令生成或更新 CHANGELOG.rst 文件：

$ catkin_generate_changelog

如果版本库中有一个或多个软件包不包含 CHANGELOG.rst，请添加 --全部 选项来填充每个软件包之前的所有提交。提交 catkin_generate_changelog 命令只会用版本库中的提交日志填充文件。由于这些提交日志并不总是适合作为更新日志，因此建议编辑 CHANGELOG.rst，使其更具可读性。编辑完成后，重要的是将更新后的 CHANGELOG.rst 文件提交到版本库。

下一步是使用以下命令在 package.xml 和 changelog 文件中提升版本：

$ catkin_prepare_release

该命令将查找软件源中的所有软件包，检查更新日志是否存在，检查是否有未提交的本地变更，递增 package.xml 文件中的版本，并使用与 bloom 兼容的标签提交/标记变更。使用该命令是确保发布版本与 bloom 一致和兼容的最佳方法。默认情况下 catkin_prepare_release 将提升软件包的补丁版本，例如 0.1.1 -> 0.1.2 。不过，它也可以提升次版本号或主版本号，甚至有精确的版本设置。请参阅 catkin_prepare_release 了解更多信息。

假设上述操作成功，则源代码已发布。

二进制版本 

下一步是使用 绽放-释放 命令来创建二进制版本。有关如何使用 bloom 的完整说明，请参阅 http://wiki.ros.org/bloom.要发布二进制软件包，请运行

$ 绽放-释放 --轨道 <rosdistro>； --rosdistro <rosdistro>； <存储库名称>；

例如，要释放 rclcpp 根据 Iron 发布的版本，命令应为

$ 绽放-释放 --轨道 烙铁 --rosdistro 烙铁 rclcpp

该命令将获取发布版本库，进行必要的更改以发布版本，将更改推送到发布版本库，最后打开一个拉取请求到 https://github.com/ros/rosdistro .

回传至已发布的版本 

所有引入的变更都应首先在开发分支上进行。一旦变更被合并到开发分支，就可以考虑将其反向移植到已发布的发行版中。不过，任何回溯代码都不得破坏应用程序接口或 ABI 在已发布的发行版中。如果可以在不破坏 API 或 ABI 的情况下回溯更改，则应针对相应分支创建新的拉取请求。新的拉取请求应添加到相应的发行版项目板，地址为 https://github.com/orgs/ros2/projects.新的拉取请求应该像之前一样运行所有步骤，但要确保针对相关发行版进行 CI 等。

回应问题 

软件包维护者还应该查看软件源上传入的问题，并对用户遇到的问题进行分流。

对于看起来像问题的问题，应关闭问题并将用户重定向到机器人堆栈交流 .

如果某个问题看起来有问题，但与此特定版本库无关，则应使用 GitHub 的 "转移问题 "按钮将其转移到相应的版本库。

如果报告人提供的信息不足以确定问题的原因，则应要求报告人提供更多信息。

如果这是新功能，请在问题上标注 "help-wanted"（需要帮助）。

任何遗留问题都应重现，并确定它们是否真的是一个错误。如果是错误，我们将非常感谢修复。

寻求帮助 

在对软件包进行维护时，可能会遇到有关一般程序或个别问题的提问。

有关一般问题，请按照捐款准则.

如对个别问题有疑问，请标记 ROS 2 GitHub 团队 (@ros/team)，团队中的人员会进行查看。