This page details the set of past and planned releases.
A release of Gazebo consists of a set of versioned Gazebo Libraries{.external}. Each library follows semantic versioning{.external}, 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.
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.
| 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 | EOL |
| 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 |
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
Nwill work with minorN+1, but code compiled against minorN+1may not work with minorN. - Patch version increased when backwards-compatible bug fixes are released.
- Pre-release version used before making stable releases, using the
~separator.
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(); |
Check out this table for a list of release and EOL dates for all versions of all libraries.
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
[email protected].