I remember hearing that Groovy released with gazebo 1.2, but would be
"upgrading" to 1.3 later on. I presumed that those two versions must be
compatible, so I didn't think much about it.

Now, it appears I was wrong, those versions are *not* compatible, after
all. Some of the code we are using for a class at the University of Texas
broke recently:

math::Pose pose = this->parent->GetState().GetPose();


Becomes:

math::Pose pose = this->parent->GetWorldPose();


That seems trivial on an individual basis, but it is causing trouble for
our students who are trying to complete a class assignment today. Some
installed ROS Groovy on their personal laptops. Others use departmental
machines on which Groovy was installed at the beginning of the semester.

Those using their own machines broke when recent
ros-groovy-simulator-gazebo updates were applied. Computer Science
department policy is not to apply non-security package updates in the
middle of the semester, so those machines continue working correctly.

This kind of change breaks the most basic concept of a ROS distribution:

Much like Linux distributions, they make it much easier for developers to
target a consistent set of libraries to develop and test on. Also, we are
providing patches for distributions so that developers are not forced to
switch to bleeding edge, unstable code just to incorporate important bug
fixes.[1]

[1] http://www.ros.org/wiki/Distributions#What_is_a_Distribution.3F

Package maintainers are supposed to provide *binary* (ABI) as well as
*source* (API) compatibility after a distribution is released. Those things
may only change *before* the next release becomes final. After that, only
bug fixes should be made.

Furthermore, API changes between releases should provide at least one
tick-tock release cycle, in which both the new and the (deprecated) old
versions are provided.

Gazebo is an excellent simulator, heavily used by many projects. Therefore,
it needs to be especially sensitive to these stability issues.
-- 
 joq