Gazebo Rollback Safety After SDF Schema Updates: Version Mismatch Behavior

Goal

Developers often rely on Gazebo’s World::Save and World::Load APIs to capture and restore simulation states. When the underlying SDF schema evolves—such as adding new elements or deprecating old ones—the snapshot contains the original SDF version. Gazebo’s load routine compares this stored version against the current simulator’s expected schema and aborts the restore if they differ, preventing silent corruption.

Unresolved Decision

There is currently no automated migration path for older snapshots to the new schema. The documentation notes that developers can write custom migration scripts, but the core library offers no built‑in solution. Consequently, any automated test or long‑running simulation that expects a silent rollback after an SDF upgrade may encounter a hard failure.

Specific Questions

1. Does Gazebo provide any internal mechanism or flag to bypass or adapt the version check during World::Load?
2. What are the documented best practices for maintaining rollback compatibility across SDF schema changes, and are there recommended migration patterns?
3. Is there a plan in the Gazebo roadmap to introduce automated snapshot migration or a more flexible version‑compatibility layer?