Hello Gazebo PMC members and Community,
Based on many discussions with individuals and reading various comments from our community, I’d like to propose changing the Gazebo release date to March and better aligning Gazebo releases with ROS. I look forward to hearing your thoughts and feedback.
Motivation
The current September release cycle for Gazebo presents several recurring challenges for both the development team and the broader robotics community. This proposal outlines a shift in the Gazebo release cadence from September to March to mitigate these issues.
Operational Sustainability
The September release schedule forces a “feature freeze” and “code freeze” during the northern summer (July and August). This creates several points of friction:
-
Contributor Availability: The most intensive period of the release cycle currently coincides with peak vacation times, placing an undue burden on core maintainers and the project lead.
-
Internship Cycles: Contributions from Google Summer of Code (GSoC) and summer interns are often difficult to merge and stabilize before a September freeze. A March release allows plenty of time for these contributions to be integrated.
-
Event Conflict: The current cycle forces the release team to manage a code freeze simultaneously with ROSCon submission deadlines. Moving to March provides a six-month “buffer,” allowing for more polished and coordinated presentations at ROSCon.
ROS Alignment
Currently, Gazebo and ROS releases are offset where the Gazebo release comes out 7 months before the paired ROS release, leading to non-overlapping support windows and confusion regarding version pairings. There has been a discussion to extend Gazebo support windows recently so that they overlap with the support windows of the ROS releases. This will be more straightforward with a March release resulting in addition of 2 months to our existing support windows such that paired releases reach End-of-Life (EOL) simultaneously.
Version Letter Synchronization: In addition, we propose skipping the letters ‘K’ and ‘L’ to align directly with the ROS 2 ‘M’ release. Starting in 2027, Gazebo and ROS 2 will share the same release letter (e.g., Gazebo-M and ROS-M), making version pairing intuitive. Additionally, release years of Gazebo/ROS pairings will be the same.
| Release Type | Support Duration | Frequency | ROS Pairing |
|---|---|---|---|
| Non-LTS | 20 Months | Odd Years (March) | Same Letter (Non-LTS) |
| LTS | 5 Years, 2 Months | Even Years (March) | Same Letter (LTS) |
Active support window policy would still apply (Gazebo Policy Update: New Backporting Policy).
Why March?
We have identified late March as the ideal “sweet spot” in the annual calendar for several strategic reasons. It provides enough time after the winter holidays to conclude the freeze phases without rushing final stabilization, while remaining far enough away from the May ROS release to avoid logistical conflicts. Releasing in May or even April would force Gazebo to compete for community attention, tutorial party participants, and shared personnel like artists, risking the release being overshadowed. By choosing March, we create two months of separation that allows both Gazebo and ROS to have their own distinct “moments” and ensures that OSRA events are well-spaced throughout the year.
Ubuntu Support Strategy
The shift to a March release cycle changes how we target Ubuntu versions. Historically, Gazebo LTS releases added a second Ubuntu version mid-cycle. Under the new cadence, we will prioritize alignment with the upcoming ROS release target. Support for the new Ubuntu LTS will be added no later than May since it needs to be available for the ROS release. There’s a risk here in trying to add support for an unstable version of Ubuntu which is why we’ll give ourselves an extra month after the Ubuntu release for things to stabilize.
Support Tiers by Release Type
-
Non-LTS Releases (Odd Years): These will only support the existing stable Ubuntu LTS available at the time of the March release. This will be the same version of Ubuntu supported by the paired ROS release.
-
LTS Releases (Even Years): Development starts on the existing Ubuntu LTS. However, the new Ubuntu version released one month after Gazebo will become the primary supported platform. The previous Ubuntu LTS version will be supported on a best-effort basis.
The “Best-Effort” Policy
For Gazebo LTS releases, the “previous” Ubuntu LTS will move to a best-effort support basis. This means CI will not run on the older platform. The core team will address regressions reported by the community as time permits, but primary development and testing will occur on the new Ubuntu LTS. The rationale for this is that most Gazebo users transition platforms alongside ROS. Since ROS officially supports only the latest Ubuntu LTS for its new releases, Gazebo will focus its resources there to ensure maximum stability for the majority of the ecosystem.
Preparing ROS Integration
Once the release is out in March, we would have two months to pair it with the upcoming version of ROS, and, if releasing an LTS, to add support for the new Ubuntu LTS (although, we’d have been preparing for this earlier). During the release of Gazebo, the ROS vendor packages will be updated such that the rolling branches point to the new version of Gazebo. This will automatically update ros_gz as well and any issues that arise during this transition will be fixed before the Gazebo release. Over the following weeks, rolling will be updated to use the testing version of the upcoming Ubuntu LTS. This will give us an opportunity for fixing any issues that might arise. When it’s time for the ROS release, the rolling branches of the vendor packages should be well tested and ready to branch off.
Proposed Transition Roadmap
We will bypass the previously planned “Kura” release to focus entirely on the new March cadence.
- Rationale: Skipping Kura reduces the burden of maintaining a release that lacks a ROS counterpart and simplifies infrastructure/tooling by avoiding exception release letters (e.g., no Gazebo-ROS vendor packages for Kura).
- Development Window: The 18-month gap between Jetty and Gazebo-M provides a significant window to land major architectural changes and roadmap items, ensuring Gazebo-M is a high-impact release.
Milestone Timeline (Gazebo-M)
| Event / Period | Date | Duration | Primary Focus |
|---|---|---|---|
| Feature Freeze | Friday, Jan 22, 2027 | ~1 month | Stabilize new features, merge pre-existing PRs. |
| Code Freeze | Monday, Feb 22 | ~1 month | Bug fixes only. |
| Tutorial Party | Feb 24 - March 5 | 1.5 Weeks | Community testing, tutorial party. |
| Internal QA/Demo Prep | March 8 - 16 | 1 Week | Final package releases and feature demo preparation. |
| Community Meeting | Wednesday, March 17 | Feature showcase. | |
| Official Announcement | Tuesday, March 23 | Release day! |
During this longer gap between Jetty and Gazebo-M, non-breaking new features will continue to be added to Jetty and older versions according to our active support window policy.
improve the synchronization of Gazebo and ROS versions 
) perhaps we can reuse it another time since we already put in the naming effort