Limits of ROS2 Message Schema Evolution: Unresolved Rollback Decision

Goal

Determine how ROS2 can guarantee safe rollback after a message schema change without redeploying nodes.

Current Constraints

• ROS message definitions (.msg, .srv, .action) are static; any change requires recompilation of all dependent packages.
• ROS2 leverages DDS, which supports limited schema evolution (e.g., adding optional fields), but the ROS2 build system does not expose this capability automatically.
• Dynamic_reconfigure and parameter event APIs allow runtime changes, yet they lack built‑in rollback mechanisms.
• Adopting DDS schema evolution risks silent failures if older nodes ignore new fields, and not all DDS vendors fully support optional fields.

Unresolved Questions

1. What formal mechanism should ROS2 adopt to enable incremental message changes with automatic rollback support?
2. How can ROS2 expose DDS schema evolution features to developers in a way that preserves backward compatibility?
3. What safeguards are necessary to prevent silent failures when older nodes receive messages with new optional fields?