Release for Foxy

[jacobperron]

We're doing our first round of releases into the ROS Foxy distro and this package should also be tagged and released (ideally the latest state of master).

Let me know if you need anything from me to help get this done.

[eboasson]

I’ll do my best, the biggest obstacle is that I need to follow a process that includes a review, and that simply takes time. There are some open PRs that I would prefer to be in, but that’s not strictly necessary.

As a heads up: what I am aiming for is to do a release that includes DDS Security support sometime in the next month. There’s been very little churn lately, we’re really mostly adding tests to it and just exercising it a bit. It would be nice if that could end up being the cyclone dds release that’s part of Foxy (assuming all goes well). But that is something that need not be decided now.

[jacobperron]

@eboasson Thanks. I'd just like to have a preliminary release that we can start rigorous testing with. It's fine to make follow-up releases, though preferably not with any new major features. I agree we can discuss the changes related to DDS Security separately.

[jacobperron]

Regarding timeline, I'd like to have a beta for Foxy ready for April 29th (which I know may be a little ambitious at this point). If we want to make that date, then we need a release for CycloneDDS in rosdistro by end-of-day tomorrow (earlier is better). Sorry for the late notice; it slipped by mind when reaching out to maintainers.

If you could provide a rough time when we can expect a release, that would be appreciated.

[nuclearsandwich]

In order to have cyclonedds in the Foxy beta, last night I made a release into foxy using 0049328 as the release tag. I modified the bloom track to indicate a git-describe style extended version name `0.5.1+osrf1@g0049328 which will get truncated by the ROS version scheme to 0.5.1. Before making subsequent releases we'll need to clear some of the specialized changes. I've got a PR forthcoming to restore the standard behavior.

I'll describe what would be ideal to me as a ROS release engineer:
If we could get a release >=0.6.0 of cyclonedds (leaving the 0.5.x track for Dashing- and Eloquent-compatible releases) that is based on 0049328 so that we could get back on an upstream release. A big concern of mine is that the more that goes into Cyclone before an eventual >=0.6.0 release the more likelihood that something not compatible Foxy being introduced. That could put us into a tough spot version-wise as we'd have to either leapfrog the 0.6.0 release or pack future Foxy patch releases into the 0.5.x space alongside Dashing and Eloquent.

I understand the appeal of trying to save the larger version bump for an anticipated feature but I think it should still be possible to celebrate DDS security in 0.6.1 or 0.6.2

[eboasson]

@nuclearsandwich @jacobperron I had to think a bit about the best way of realising this:

If we could get a release >=0.6.0 of cyclonedds (leaving the 0.5.x track for Dashing- and Eloquent-compatible releases) that is based on 0049328 so that we could get back on an upstream release.

because that seemed to me, too, to be the most attractive option for ROS2.I also don't see a real problem for Cyclone doing the same. The complication is in juggling the Eclipse release process: I have to file a request, append IP logs, get it reviewed and approved. The review scheduling in turn determines the release timing for me.

What I think is the best compromise I can do: I can create a releases/0.6.x branch at that specific commit (probably + some administrative commits for documentation typos, README, bumping of version numbers), and then only add to that what is required to get it released.

Would bloom accept a 0.6.0rc1 tag? It would be easy for me to tag it like that.

[nuclearsandwich]

The complication is in juggling the Eclipse release process: I have to file a request, append IP logs, get it reviewed and approved. The review scheduling in turn determines the release timing for me.

This is news to me. My apologies for downplaying the amount of labor being requested, doubly so if I've bandied the "version numbers are free" line at you. We don't have an explicit process for requesting versions from vendors but @jacobperron and I are accumulating release management info for ROS and I'll make sure we add a section that proposes one.

What I think is the best compromise I can do: I can create a releases/0.6.x branch at that specific commit (probably + some administrative commits for documentation typos, README, bumping of version numbers), and then only add to that what is required to get it released.

Would bloom accept a 0.6.0rc1 tag? It would be easy for me to tag it like that.

This would absolutely work for us. I'd still do a similar non-standard release but rather than using the arbitrary commit ID I'd use the rc1 tag. The version in ROS will still be truncated to 0.6.0 but that's a much more accurate reflection of what's being released and we would be able to update to 0.6.0 official in a revision.

Thanks very much for finding a compromise with us!

---

If I can piggyback here, we also need a release of rmw_cyclonedds. My understanding is that rmw_cyclonedds is not an Eclipse project and so doesn't require the Eclipse release process. If that's not incorrect, it would be great if a maintainer of the package was able to tag a release (and bloom it) but if you'd like someone from the ROS team to do so I am willing to volunteer.

[eboasson]

If I can piggyback here, we also need a release of rmw_cyclonedds. My understanding is that rmw_cyclonedds is not an Eclipse project and so doesn't require the Eclipse release process.

Correct.

If that's not incorrect, it would be great if a maintainer of the package was able to tag a release (and bloom it) but if you'd like someone from the ROS team to do so I am willing to volunteer.

Of course we can do that, you are also free to do it. You may have seen ros2/rmw_cyclonedds#174, I presume you'd want to wait for that to be fixed? (It shouldn't be long.) Feel free to just bump the version number and tag it anyway if that's more practical.

If you'd have time to do the blooming, that would be ideal. @ThijsSassen has done it once or twice now but he tells me it is somewhat tricky to get bloom to actually go through all the steps without causing trouble (I suppose it is some environment thing) and it seems like you have a good routine with it.

[jacobperron]

I'm going to bloom rmw_cyclonedds now.

[JWhitleyWork]

This has been done for some time. @eboasson Can you please close?