search

space-ros / docs

The Space ROS documentation site.
Creative Commons Attribution 4.0 International
9 stars 10 forks source link

Update Dev/Release Branch Procedure #33

Open Bckempa opened 7 months ago

Bckempa commented 7 months ago

During https://github.com/space-ros/space-ros/discussions/126 discussion of https://github.com/space-ros/space-ros/discussions/130 to address https://github.com/space-ros/space-ros/issues/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:

Ryanf55 commented 7 months ago

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:

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

Bckempa commented 7 months ago

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 commented 7 months ago

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.