ROS2 variant and dependency versioning for deployment

edit

Hello, Looking for advice on how others have approached the following situation with a base ROS variant (ie, ros-base) and corresponding ROS dependencies (resolved through rosdep).

Consider a released ROS2 Docker application that has been built off of ros-${ROS_DISTRO}-ros-base and has used rosdep to resolve the dependencies of custom packages used in the application. If this release is built, say on a given date, and it turns out a feature/fix (with a new dependency) needs to be added to the release at a later date, there is no guarantee that the versions of the ROS variant and dependencies will be the same. I believe this is due to the following:

1. Specifying a version of a dependency in a package's package.xml is not handled by rosdep [Refs: #q254811, https://github.com/ros-infrastructure... ]
2. ROS debian binaries (generated by bloom) do not specify specific versions of package dependencies in the CONTROL file (see example CONTROL file for ros-humble-ros-base below) and apt uses this for install
3. I do not believe there exists a "snapshot" apt mirror for ROS or Ubuntu packages, like Debain provides [Refs: https://snapshot.debian.org/ ]

I know that breaking changes to ROS packages are not allowed/expected in a given distribution but there could be instances in which a package has unintentionally introduced a bug or breaking change. It would be ideal to "lock" the version of the variant and the corresponding dependencies to prevent unintentional regressions in the release and reduce the testing required to ensure a "dot" release is stable.

Sooo...what do others do in this situation? Deal with any breaks/regressions when a old releases need to be updated and rebuilt?

Here are some of the ideas I had:

1. Make a snapshot of the apt mirror(s) used to build specific releases and tie the mirror sources to the release [Ref: #q236249 ]
2. Build ROS variant and dependencies from scratch using the following approach: fork https://github.com/ros/rosdistro, create a branch off of the desired <distro date=""> tag, manually generate the compressed cache file using </distro>rosdistro_build_cache, update the _index.yaml_ and _index-v4.yaml_ distribution_cache URL with the manually generated cache file, use ros_install_generator with the ROSDISTRO_INDEX_URL point to the index.yaml to generate a _.repos_ file which can be used to build the ROS variant.

The issue I ran into with approach #2 was that I still needed to use rosdep to resolve the Ubuntu dependencies of the packages contained in the .repos file, which introduces the same non-versioned issues as above.

ros-humble-ros-base CONTROL File:

Package: ros-humble-ros-base
Version: 0.10.0-1jammy.20230428.163401
Architecture: amd64
Maintainer: Steven! Ragnarök <steven@openrobotics.org>
Installed-Size: 41
Depends: ros-humble-geometry2, ros-humble-kdl-parser, ros-humble-robot-state-publisher, ros-humble-ros-core, ros-humble-rosbag2, ros-humble-urdf, ros-humble-ros-workspace
Section: misc
Priority: optional
Description: A package which extends 'ros_core' and includes other basic functionalities like tf2 and urdf.