Releases, Versioning, and Public API claim of ros-controls

[christophfroehlich]

We’re happy to share the release policy for all ros-controls packages, which the PMC has recently finalized and published.

tl;dr

• We don’t guarantee ABI stability (Rebuild after any upstream package update!).

• We allow code to be deprecated in every release (don’t use -Werror=deprecated-declarations).

• We define the release within a distro “stable” at October 1st after an official distro release (which means that Kilted reaches stable state this week). The goal is that we get the stable release available by ROSCon.

• We still allow API breaks and behavior breaking changes within such stable releases in case of safety concerns.

• We always try to give useful hints in the migration guides and deprecation notices.

You can read the full policy on control.ros.org.

Did you know?

You can always build the rolling version including latest features back on all active distros! Look for “Development version” in the installation instructions.

[christian]

Does the ABI follow the same “breaking changes” rules as the API? Will the ABI also be “mostly” stable after Oct 1st and only change in case of “safety concerns”, or will it be unstable for the full duration of a ROS release? I.e. if the API does not change after Oct 1st, can the ABI still change?

[christophfroehlich]

@christophfroehlich

We don’t guarantee ABI stability

We have discussed this a bit more in detail in the linked section:

• ABI of plugins may change at every release, i.e., also within a stable ros2_control release. Plugins built by the buildfarm will still be loaded by pluginlib’s class loader, but code linking against the exported libraries will break.

• For non-plugin code, ABI breaks within a stable ros2_control release are less likely but still unavoidable to fix code, which is critical regarding safety aspects of robot control.