ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

Gazebo version in is quite outdated?

Hi, I’ve just found out that there is a big difference in version numbers of Gazebo pulled from and from

$ apt-cache policy libgazebo9
  Installed: 9.11.0-1~bionic
  Candidate: 9.11.0-1~bionic
  Version table:
 *** 9.11.0-1~bionic 500
        500 bionic/main amd64 Packages
        100 /var/lib/dpkg/status
     9.0.0+dfsg5-3ubuntu1+ppa2 500
        500 bionic/main amd64 Packages
        500 bionic/main amd64 Packages
     9.0.0+dfsg5-3ubuntu1 500
        500 bionic/universe amd64 Packages

Why is that? I understand ROS doesn’t want to tie with Gazebo release schedule, so I’d expect a 1-2 version delay against the osrfoundation repo, but not 11! Is this a desired state? I thought Gazebo is distributed as one of the core packages for ROS, so I’d expect better support…

9.0.0 and 9.11.0 were less then 18 months apart as far as I can tell, though they are minor version bumps. I’m unsure what the policy is for updating packages that see a minor version bump for an LTS release (I think they’re supposed to).

Hello Martin:

The notable difference between the ROS/Ubuntu repositories of gazebo9 versions and the ones present in the repositories can be explained by joining different factors all together:

  • serves as the upstream repository for Gazebo (similar to what pip can represent for python projects). Note that the bump in minor/major versions does not always mean an important development. When a new version of ROS is defined (REP-3) the Gazebo team tries to sync the releases to provide the latest code to it (through Ubuntu). hosts the latest versions of Gazebo what does not mean that is what ROS users want.
  • When an Ubuntu release is open for development, it closes the inclusion of major versions one month before the release date. Bionic closed the inclusion of gazebo releases in March 2018. Once Ubuntu releases a distribution (and @safijari mentioned part of this), upload new software updates is pretty difficult (under the policy of Stable Release Updates, mostly restricted to critical/security bugs).
  • What could be done is to update the ROS repository with packages coming from That goes against the principle of uploading different versions of the software provided by Ubuntu to the ROS repo only in critical cases. That also could potentially impact in the ‘stability’ (particularly speaking about the runtime behaviour) of Gazebo by the ROS uses. And if someone needs new features from gazebo9 the solution of adding the extra repository is easy and does not affect the stability of the simulation experience for the rest of ROS users.

With these points in mind the current decision is to not to upload to the ROS repository new versions of Gazebo 9. As usual, the decision is up to debate if we (ROS community) find a good reason to change it.


With dozens of robots in production the developers at my company would appreciate us not changing this strategy. If we absolutely need a newer version of a package we figure that out ourselves and prefer repo packages for LTS released to remain largely unchanged (critical bugfixes aside).

Non LTS released are fair game tho in my opinion.

I must admit I haven’t even known gazebo is released into ubuntu repos. I knew only about ROS and Gazebo repos.

Generally, not changing functionality would be nice during a single release, but the problem with Gazebo is it mixes up news with bug fixes in minor versions. Or does the Ubuntu/ROS repo version just cherry-pick bugfixes?

On the other side, Gazebo has pretty thorough ABI/API stability requirements during a major release, so at least from this point of view, there shouldn’t be any surprises…

Using non LTS for unstable changes is a good topic for discussion. At this point we can provide that experience of using latest Gazebo with ROS simply by adding another repository, which I think is an easy way for users that need it.

This is right and as far as I know valid following the point 7 of the semantic versioning manifesto. The effort needed to port bugfixes in all the maintained major/minors combinations can become a nightmare for a project of the size of Gazebo. Bumping a minor should not open the door to modify simulation behavior and although some of the changes can potentially affect it in many ways, we can discuss when that happen if that is a regression that needs to be reverted.

No. Only critical bugfixes or security patches are the ones that we can cover at this point for Ubuntu and ROS repositories.

Okay, thanks for the clarification. To save future users from this confusion, I sent a PR to gazebo_tutorials which adds a note explaining the situation: . Feel free to look at it and help with rewording it.