How to release and run different flavours of ros_ign packages

[j-rivero]

The original request is from @chapulina. This issue speaks only about the issue of having binary packages supporting different ROS distros and different Ignition distros. A source build for these combinations seems to be possible after changes in pr #72

A release of ros_ign code should ideally fulfill the following requirements:

1. Package names in code repository should be maintain
   i.e: do not modify ros_ign or ros_ign_bridge
2. Multiple ROS distributions and multiple ROS packages for the different distributions
   i.e: ros-melodic-ros-ign and ros-noetic-ros-ign
3. Multiple Ignition versions and multiple packages for the different ignition versions
   i.e: ros-melodic-ros-ign-citadel and ros-melodic-ros-ign-blueprint
4. Packages must be co-installable
   problem: filesystem paths are the same within the same ROS distribution since package names are the same
5. Packages should install ROS code in the way that versions can be selected at launch/runtime
   problem: how to rosrun/roslaunch different code if package name is the same

[j-rivero]

Without touching how the code is organized in the repo right now:

• 1, 2 and 3 can be implemented using a bit of bloom templates magic to change debian package names
• 4 and 5 affects where the code will be in the filesystem

Without asking the user for changing ROS_PACKAGE_PATH I don't find a way of having 4 implemented without altering the file paths (include/, lib/ or share/ for example).

The 5 is even more difficult without implementing a wrapper in the source code that accepts an input about which Ignition version the user wants to run and loads different code. Combining both, different filesystem location for one the packages and the wrapper (altering ROS_PACKAGE_PATH at runtime to find that different location) we could try to get all the points.

[chapulina]

tl;dr Let's drop requirements 4 and 5 and have only one ros_ign version at a time per ROS distro.

---

Some more considerations:

• Citadel is in https://packages.ros.org for Focal / Buster (rosdep: add Ignition Citadel ros/rosdistro#24934)

• Each ROS version will support an official Ignition version, the same way as it supports an official Gazebo version:

  • REP-2000: Foxy - Citadel
  • REP-0003: Noetic - Citadel

• We should release ros_ign for the officially supported version on https://packages.ros.org. Right now, this means:

  • ros-noetic-ros-ign is Citadel
  • ros-foxy-ros-ign is Citadel

• We could also retroactively make it official that ROS Melodic goes with Ignition Blueprint (the current combination used by SubT), so:

  • ros-melodic-ros-ign is Blueprint

• To prevent creating multiple sets of ros_ign packages that don't talk to each other, we should not release unofficial versions upstream. i.e. we shouldn't have any Blueprint / Dome packages in https://packages.ros.org for Focal.

• We should offer alternative non-official combinations for users who really know what they're doing. Those would be released into https://packages.osrfoundation.org like unofficial gazebo_ros_pkgs versions. This could break point 4 above, "Packages must be co-installable". I think it wouldn't be too terrible if we said that ros-noetic-ros-ign conflicts with ros-noetic-ros-ign-dome, because we should really be encouraging users to use the official combination.

• If we drop point 4 like suggested above, then point 5 disappears.

---

What do you think, @j-rivero ?

[chapulina]

The team has discussed this a while back and I believe there are no objections.

Here's the plan:

ROS 1

• Support choosing Blueprint / Citadel for Melodic: Choose collection based on environment variable #72
• Add Noetic support (Citadel only): Noetic support #93
• Clean up installed headers for Melodic: Install only what's necessary, rename builtin_interfaces #96
• Port ☝️ to Noetic (rebased commitless noetic branch)
• Bloom Noetic to https://packages.ros.org with Citadel support: ros_ign: 0.111.0-1 in 'noetic/distribution.yaml' [bloom] ros/rosdistro#25911
• Create support for package renaming in -release repository, DSL code needs to be adapted in release-tools: Support to use ignition_version to release ign_ros_bridge gazebo-tooling/release-tools#249
• Bloom Melodic to https://packages.osrfoundation.org with Blueprint support

ROS 2

• Support choosing Blueprint / Citadel for Dashing / Eloquent (port Choose collection based on environment variable #72)
• Update Foxy CI to use Citadel from https://packages.ros.org: Update Foxy CI #94
• Clean up installed headers for Dashing / Eloquent: Install only what's necessary, rename builtin_interfaces #95
• Port ☝️ to Foxy dashing ➡️ ros2 #97
• Bloom Foxy to https://packages.ros.org with Citadel support: ros_ign: 0.221.0-1 in 'foxy/distribution.yaml' [bloom] ros/rosdistro#25912

---

An open question is how to version all these releases. I propose the following scheme:

• Melodic: 0.X
• Noetic: 1.X
• Dashing: 2.X
• Eloquent: 3.X
• Foxy: 4.X

[j-rivero]

What do you think, @j-rivero ?

Sorry did not answer here although we speak in person. +1 to all the plan, sounds like the best approach to me and it is the same we are doing with gazebo_ros_pkgs.

Here's the plan:

The whole plan looks good to me. We might need to change something in release-tools along the way but we can cover it as we go forward. I think we need a place to store this information (official vs unofficial releases, naming, versioning, etc.).

An open question is how to version all these releases. I propose the following scheme:

* Melodic: 0.X

* Noetic: 1.X

* Dashing: 2.X

* Eloquent: 3.X

* Foxy: 4.X

An alternative could be ROS1/ROS2/ROSN and the second for releases:

• Melodic: 1.1.X
• Noetic: 1.2.X
• Dashing: 2.1.X
• Eloquent: 2.2.X
• Foxy: 2.3.X

This way we reserve 'space' in the case of new ROS1/ROS2 releases appear, the first number gets a meaning and we don't go too far with versions (that is pure cosmetic). Another option could be to sync with gazebo_ros_pkgs and use the same 2.x and 3.x numbers we have there.

[chapulina]

I think we need a place to store this information (official vs unofficial releases, naming, versioning, etc.).

Good point, I'll open a PR documenting this within this repo.

the first number gets a meaning

I like that the numbers will have meaning. This means we won't be using semver though. So we should document what minor and patch bumps mean, as well as what's our API/ABI policy.

I have a slight preference for bumping a major for each ROS distro so we can piggyback on ROS 2's versioning guidelines.

Another thing to consider is not to bump above 1.0 yet so we don't commit to API stability. In that case, we could keep 0.X across all distros, and use different minors to differentiate them, for example:

• Melodic: 0.10.X
• Noetic: 0.11.X
• Dashing: 0.20.X
• Eloquent: 0.21.X
• Foxy: 0.22.X

[j-rivero]

I like that the numbers will have meaning. This means we won't be using semver though. So we should document what minor and patch bumps mean, as well as what's our API/ABI policy.

Oh I assumed that in ROS, specially in ROS1, we don't quite follow semver.

I have a slight preference for bumping a major for each ROS distro so we can piggyback on ROS 2's versioning guidelines.

Good resource indeed.

Another thing to consider is not to bump above 1.0 yet so we don't commit to API stability. In that case, we could keep 0.X across all distros, and use different minors to differentiate them, for example:

* Melodic: 0.10.X

* Noetic: 0.11.X

* Dashing: 0.20.X

* Eloquent: 0.21.X

* Foxy: 0.22.X

Like it, deal.

[chapulina]

@j-rivero , I documented some of the things discussed here on #99. Let me know what you think. I kept the version numbers at 0.X, but went a bit crazy and added one more minor digit 😄

[j-rivero]

Bloom Melodic to https://packages.osrfoundation.org with Blueprint support

We currently host packages for ros_ign bridge in Melodic:

jrivero@nium ~ $ apt-cache show ros-melodic-ros-ign-bridge 
Package: ros-melodic-ros-ign-bridge
Version: 0.9.3-3bionic
Depends: libc6 (>= 2.14), libgcc1 (>= 1:3.0), libignition-msgs4, libignition-transport7, libprotobuf10, libstdc++6 (>= 5.2), libignition-msgs4-dev, libignition-transport7-dev, ros-melodic-geometry-msgs, ros-melodic-mav-msgs, ros-melodic-message-runtime, ros-melodic-nav-msgs, ros-melodic-rosconsole, ros-melodic-roscpp, ros-melodic-rosgraph-msgs, ros-melodic-sensor-msgs, ros-melodic-std-msgs, ros-melodic-std-srvs, ros-melodic-tf2-msgs

For this new release we would be changing names to ros-melodic-ign-*-blueprint, right? We want the current packages to be automatically updated to new names?

[chapulina]

For this new release we would be changing names to ros-melodic-ign-*-blueprint, right?

Oh no, I think that would break SubT. I think we agreed that ros-melodic-ros-ign will be compiled against Blueprint and we won't provide Citadel debs for now.