Update Dev/Release Branch Procedure

[Bckempa]

During #126 discussion of #130 to address #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.