Update Dev/Release Branch Procedure

[Bckempa]

During space-ros/space-ros#126 discussion of space-ros/space-ros#130 to address space-ros/space-ros#101 lead to @ivanperez-keera further fleshing out the branching and release strategy which leaves the main development branch able to target branch heads in spaceros.repos while leaving the rosinstall generated ros2.repos pinned to the upstream ROS distro release and fixes the versions of all packages when creating new tagged releases on a stable/release branch.

The following needs to be updated to match:

• space-ros/CONTRIBUTING.md
• docs/source/How-To-Guides/Releasing-Space-ROS.rst

[Ryanf55]

Hello! Great to see the work SpaceROS is putting in for reproducible builds.

This was discussed in the ROS 2 production working group. I agree with the proposed workflow as it is what I use. This workflow has the advantage that it's easy to pull in the latest version during development with vcs pull but makes it easy to reproduce all the sources in just a few automated commands.

See related:

• DIscussion on freezing sources in vcstool2 (a proposed successor to vcstool) vcs freeze MaxandreOgeret/vcstool2#7
• Building and packaging custom forks of ROS 2 Easy to use build and package tool for a custrom forks of ros2 bpwilcox/ros2-production-working-group#7

For packages installed with apt, is there a need to reproduce previous versions, or is that out of scope?

[Bckempa]

Thanks for linking that discussion, it is great input.

We're working on updating our process and tooling based on what we learned from our last release (mostly updating tooling that only expected branches to also accept tag names), but so far the package pinning seems to work quite well.

We've been letting rosdep installed packages installed the latest version from apt since we're on an LTS distro and calling that good enough while we nailed down our workspace pinning, but that is next on our list so any insight you have on the best way to do that would be helpful.

[Ryanf55]

Thanks for linking that discussion, it is great input.

We're working on updating our process and tooling based on what we learned from our last release (mostly updating tooling that only expected branches to also accept tag names), but so far the package pinning seems to work quite well.

We've been letting rosdep installed packages installed the latest version from apt since we're on an LTS distro and calling that good enough while we nailed down our workspace pinning, but that is next on our list so any insight you have on the best way to do that would be helpful.

Thanks! I've found exact pinning is only required for deployment to tests or production, and thus is tied to the deployment method. For docker, one common technique is a multistage dockerfile that can pin all the apt dependencies in a layer, and is stored on a docker package registry for eternity. This meets our needs, but is only useful for projects that use docker.

Conveniently, this recent ROS discourse thread is also related for those using a debian-based OS: https://discourse.ros.org/t/how-to-build-full-ros2-deb-packages-for-debian-distribution-which-are-built-from-source-code/35969/4

For some certifications, I could see this being not good enough. The Ubuntu developers are notoriously conservative with regards to updating packages in an LTS distribution, which is annoying for a quickly moving project, so we end up building a lot of packages from source either to fix bugs or better integrate with a CMake build system when the LTS version only comes with PkgConfig.

This is a solved problem when using Yocto with meta-ros because Yocto is fully reproducible. For larger companies that deploy to Linux and can support building their own Linux distro, this option is most attractive.

[ivanperez-keera]

The steps we followed for the release today were:

• Add next milestone.

• Add next filter in the project view.

• De-scope or move unfinished issues/PRs.

• In each space-ros repo, create a release branch with the name release-humble-2024.10.0

• Git pull of space-ros repo, checkout release branch.

• Run the repos update

• Open a PR for that update

• Build using ./build.sh

• Check images with ./run.sh

  • ros2 topic list shows default topics.
  • Try ikos (only because the current tests ignore it).

• Clone docker repo.

  • build moveit2 with ./build.sh
  • build nav2 with ./build.sh
    • Test nav2 opening rviz
  • build space_robots with ./build.sh
    • Test space_robots with ./run.sh
      • open curiosity demo. Send commands. See that it reacts.
      • open canadarm demo.

• Merge the PR, closing the issue.

• Tag the main HEAD for every repo.

• Push all tags.

• Create releases in each repo, creating a discussion.