ros2/rosbag2

How to roll existing code into humble releases?

thomasegriffith opened this issue · 2 comments

thomasegriffith commented

Apologies if I'm overlooking some doc, but I can't seem to find how "new" code gets rolled back into the latest humble release.

As far as I can tell release-humble-20230614 is on version 0.15.6 of rosbag2, which seems a bit old considering the latest is 0.24.0.

The reason I ask is that there are some missing pybind functions for SequentialWriter in 0.15.6. I specifically need split_bagfile(). I see the C++ code in 0.15.6, but the pybind is simply missing. The pybind was added to rolling 7 months ago.

Anyway, what's the process for getting code like this added to the next humble or 0.15.x release?

Thanks in advance!

MichaelOrlov commented

Usually, the process is to create backporting PR to the humble branch without breaking API/ABI changes and get it reviewed and merged. Then ask maintainers to cut release for the humble.
As soon as rosbag2 will have a new label and release it will be included in the next ROS 2 synch and become available in binary form via ROS distribution.

emersonknapp commented

@MichaelOrlov is correct. The process is only briefly touched on in https://docs.ros.org/en/iron/The-ROS2-Project/Contributing/Developer-Guide.html?highlight=backport#guidelines-for-backporting-prs - it doesn't say how to backport though. Here's a brief description, and I will close this issue as not actionable

  1. Find the change that creates the feature you want - PRs are squashed into a single commit and the PR number linked in the commit text, so this should be relatively easy via git blame
  2. Create a new branch backport-<PR NUMBER>-<TARGET DISTRO>
  3. git cherry-pick the commit to be backported
  4. Open a PR against <TARGET_DISTRO> branch

Note that the above may not fully reach the solution needed. In some cases code has diverged too much to easily backport, and if a solution exists to still implement the feature or fix, then it will have to be written pretty much from scratch. In that case, you can open a PR against the release branch as normal, but follow the naming convention and link to the original PR that implemented the change in the description.