Plugin API struct field removal across Gazebo version boundary

Gazebo plugin binaries compiled against an earlier major release (e.g., Gazebo 11) may fail to load on a subsequent version due to removed struct fields and unresolved symbol references. This API surface shift occurs between major Gazebo releases without a stable ABI layer, leaving no native mechanism for plugin version pinning or automatic compatibility shims. Consequently, users must manage runtime version selection through manual symlink adjustments or Docker image tagging, which introduces overhead and risks library dependency mismatches.

World format attribute drift between Gazebo Fortress and Ignition Gazebo similarly affects cross-version world loading. Attributes such as link pid and sensor updateRate have been restructured, causing worlds to load with missing or default values when transferred between releases. Manual world file edits are often required, yet these modifications can alter physics parameters and impact simulation stability.

What mechanisms does Gazebo offer for plugin API version abstraction across major releases? Is there a documented world format migration path that preserves link and sensor attributes without manual editing? How do Rosbridge scripted recovery workflows adapt to transport API signature shifts between Ignition and ROS 2 Gazebo without code changes?