Track request: Gazebo citadel

store-requests
1

Hi,

Could I get a citadel track for gazebo (currently unlisted)?

Thx.

2

Hello,

gazebo has no existing tracks, so per Process for aliases, auto-connections and tracks , we need a 1-week voting/discussion period, so I’ll check back on the discussion and votes in a few days.

I have a few questions before casting my vote.

  1. What’s Gazebo’s release cadence, how often is a new version (potentially requiring a new track) released? is this documented somewhere by upstream?
  2. What’s the nomenclature for versions? what’s citadel?
  3. Is there some commitment from upstream on maintenance of old versions?
  4. Are new versions backwards-incompatible? meaning, if I was running e.g. version X and try to install X+1, will that just work, or do I need to migrate my data/configuration, or will things break horribly?

Thanks!

  • Daniel
3

Hi @roadmr, thx for the prompt reply.

For me to understand, “gazebo has no existing tracks” means no actual candidate/stable release(s) right? 'Cause there is a beta one.

For a bit of context, we are planning to roll out a beta test of this snap at its citadel version. So we’d like to roll it out on a proper citadel track so that we can get started snapping the newer version.

Now to answer your questions,

  1. The planned release cadence for Gazebo is one release per year, with an LTS every two years. Not sure yet if we will release non-LTSs on their own tracks or only have a ‘rolling’ latest track. At the moment there are two on-going LTS releases. We will thus open another such request in a few weeks. The release cycle is documented on the Gazebo release page.
  2. From the same release page linked above: “A release of Ignition consists of a set of versioned Ignition Libraries. […] An Ignition release follows the form “Ignition Codename”, for example Ignition Acropolis. The codename is alphabetically increasing, and chosen to fall loosely within the architectural domain.”.
  3. There are clearly defined EOL date. For instance citadel will be maintained until Dec, 2024.
  4. These releases come with Major version increases of the underlying libraries. Thus they are not backward compatible. Especially, they are not going to be compatible with the external software they are interacting with (ROS project on host machine). I’m not sure about its own data/configuration files tho.

Some extra info,

  • Gazebo is formerly known as Ignition Gazebo. The upstream team is in the process of renaming. We’re ahead of them on the snap name but we are planning on requesting an alias for backward compatibility. I assume that’s a separate request?
  • Gazebo is the official robotics simulator for the ROS project and thus tends to stick to ROS release cadence which is itself tied to Ubuntu release cadence (ROS H based on Jammy should be released soon).

Let me know if you need further info!

4

Hi :slight_smile: beta is a risk under the latest track which all snaps have by default.

Channels are better explained here and here - I would suggest a read of those resources to get more clarity on how tracks work and how they relate to a channel specification (track/risk/branch).

I understand your use case, it should be fine to have a citadel track for that version, and working on the newer/latest one in the latest track. Each track has all the four typical risks (stable, candidate, beta and edge) under it.

In any case, given the information you provided, I’m +1 on creating a citadel track for Gazebo. I’ll check back in a few days to see if other reviewers have also voted.

  • Daniel
1 Like
5

+1 from me as well :slight_smile:

1 Like
6

Thanks for your patience, the citadel track has been created.

  • Daniel
1 Like