Gazebo Releases#

This page details the set of past and planned releases.

What is a Release?#

A release of Gazebo consists of a set of versioned Gazebo Libraries. Each library follows semantic versioning, and the major version of a library is guaranteed not to change with an Gazebo release. This essentially means you can develop code against a release of Gazebo without the worry of breaking changes being made upstream.

Naming Scheme#

A Gazebo release follows the form “Gazebo Codename”, for example Gazebo Acropolis. The codename is alphabetically increasing, and chosen to fall loosely within the architectural domain.

Release List#

Name

Date

EOL date

Notes

Jetty

Sep, 2025

Sep, 2030

LTS

Ionic

Sep, 2024

Sep, 2026

Harmonic

Sep, 2023

Sep, 2028

LTS

Garden

Sep, 2022

Nov, 2024

Fortress

Sep, 2021

Sep, 2026

LTS

Edifice

Mar, 2021

Mar, 2022

EOL

Dome

Sep, 2020

Dec, 2021

EOL

Citadel

Dec, 2019

Dec, 2024

LTS

Blueprint

May, 2019

Dec, 2020

EOL

Acropolis

Feb, 2019

Sep, 2019

EOL

Library Versions#

Gazebo adheres to semantic versioning, with the addition that ABI is considered part of the public interface. In summary:

  • Major version increased when incompatible ABI/API changes are made.

  • Minor version increased when functionality has been added in a backwards-compatible manner, but it may not be forward-compatible. That is, code compiled against minor N will work with minor N+1, but code compiled against minor N+1 may not work with minor N.

  • Patch version increased when backwards-compatible bug fixes are released.

  • Pre-release version used before making stable releases, using the ~ separator.

Deprecation strategy#

Where possible, a tick-tock deprecation strategy is used during major version increments. Deprecated code produces compile-time or runtime warnings (tick). These warnings serve as notification to users that their code should be upgraded. The next major release removes the deprecated functionality (tock).

Example of function foo deprecated and replaced by function bar:

Version

API

gz-(N)

void foo();

gz-(N+1)

void foo() GZ_DEPRECATED(N+1);
void bar();

gz-(N+2)

void bar();

Support lifecycle#

Check out this table for a list of release and EOL dates for all versions of all libraries.

Supported platforms#

Platforms are defined as a combination of operating system and architecture. For example, “Ubuntu Noble on amd64”.

Each release is targeted at a specific set of platforms. A support level applies to an entire Gazebo release, including all library versions within it. The supported platforms for each release are listed on their home pages (i.e. Harmonic).

In general, there are three categories of support for a platform:

  • Official support: Officially supported platforms are regularly tested on continuous integration and released as binary packages. Errors or bugs discovered in these platforms are prioritized for correction by the development team. Significant errors discovered in these platforms can impact release dates and we strive to resolve all known high priority errors in officially supported platforms prior to new version releases.

  • Best-effort support: Platforms supported at best-effort may be regularly tested on continuous integration and / or released as binary packages. Errors may be present in released versions for these platforms. Known errors in best-effort platforms will be addressed subject to resource availability on a best-effort basis and may or may not be corrected prior to new releases.

  • No effort to support: All platforms not included under official or best-effort support are considered not supported. If a release is functional in a platform that isn’t supported at a point in time, there are no guarantees that it will remain so in the future. Pull requests addressing issues on these platforms may be considered if they don’t break any supported platforms and reviewed as time allows.

If you or your company are interested in directly supporting, or sponsoring the support of other platforms, please contact info@openrobotics.org.