Hi ROS community! 
Have you ever debugged a problem on Humble or Jazzy for hours… only to discover the fix already existed on rolling, but was never backported? 
You’re not alone — and I’d like to fix this systematically.
The pain
In principle, all bug fixes should be backported to the supported downstream distributions — precisely because they are fixes. Today, however, this depends entirely on the maintainer’s manual effort and judgment, so backports happen on a need-to-do or requested basis rather than automatically and systematically.
One of the key blockers: it’s not always easy to tell whether a fix is ABI compatible with released distributions just by looking at the source code. This depends on developer skill and experience.
And too often, community developers hit a bug on a released distro, dig all the way down to the root cause, and only then find the fix was already merged to rolling — so they have to request the backport themselves. That’s wasted effort for everyone. 
Making this automatic would save significant time for maintainers, developers, and users alike. Original discussion: ros2/rclcpp#2555
The prototype (working today!)
I built this as two GitHub Actions:
libabigail-action — generic, repo-agnostic. Diffs two shared libraries with libabigail’s abidiff. Useful for any C/C++ project, not just ROS!
ros2-abi-action — the ROS-aware layer. For every PR it:
- builds the package twice (target branch + PR head) in the matching distro container
- runs the binary ABI diff
- applies REP-0009 policy automatically: strict
for released distros, advisory 
for rolling - surfaces results as a sticky PR comment,
ABI compatible
/ ABI break
labels, and a pass/fail check
Maintainers can decide on backports at a glance. And the per-repo integration is a ~10-line workflow file, so rclcpp, rcl, rcutils, rmw and friends can all share the same setup. 
Small print: an ABI compatible label is information, not an obligation to backport — behavioral changes can still surprise users even when ABI is intact. And this is binary ABI only; header templates/inlines still need human eyes. 
I’d love your feedback
- Does this approach make sense for ROS 2 core repos? Concerns about CI cost or noise?
- Tooling: libabigail vs. the older abi-compliance-checker (used by industrial_ci / auto-abi-checker) — experiences?
- Should we go further and wire the
ABI compatiblelabel into the Mergify backport flow?
- Would community packages benefit from this as a shared reusable workflow too?
Comments, use cases, and contributions all very welcome! 
Tomoya