i would like to open discussion and have feedback from community.
Problem
Development and Operation Burden: maintainer and developer burden to check ABI compatibility for backport.
Quality: we sometimes miss backporting for released distribution unless requested. (bug fixes basically should be backported to available distribution to keep the consistent quality for all supported distribution.)
Proposal
Integrate ABI/API compliance checker in github workflow to check ABI compatibility for every PR to see if the fix can be backported automatically with label.
What’s in it for us?
User: Quality Improvement, potentially all bug fixes that ABI compatible with can backport to already released distribution.
Developer/Maintainer: Cost Effective, automatically determine if the fix is backport-able for already released distribution. (automatically labeled.)
Great idea! I have always wondered how to check ABI compatibility so if somebody can produce an example package that demonstrates how to incorporate this into a ROS2/cmake workflow, that would be awesome. I’d definitely use it.
Is this going to be just for rclcpp for now, or are you planning on making this accessible to all ros packages, maybe by providing an ABI check via action-ros-ci?
@fmauch i was hoping this kind of feature is already available somewhere! thanks! i am not sure if we can just rely on this CI with github workflow, but definitely look into this.
I’d love a github action for this - it would take out some of the ambiguity when I’m doing backports for syncing to released distributions in Nav2. Even if it just tags which could be backported, that would be a big acceleration in the release process. If it automatically triggered the backports for distributions that it was API/ABI compatible for, that would be even greater!
The only thing that wouldn’t immediately solve is what happens when a PR itself isn’t ABI/API breaking, but depends on previous work that was and thus not backported. I assume the crazy merge conflicts would make that clear in the ensuing PR - but if it could detect that as well (depends on a change from main that wasn’t backportable), that would let us basically completely automate the main → humble, iron, jazzy syncs in big projects like Nav2! But that’s probably out of scope, just something that I run into as well when I’m backporting for release syncs.