Add preprocessor logic to preserve compatibility with Foxy in master

[ivanpauno]

This is a question and a PR at the same time.

Currently, foxy branch is being used in rmw_cyclonedds to target Foxy.

In the past, it was desired to maintain several versions from the same branch (dashing-eloquent was split to a separate branch due to several breaking changes in Foxy).

Considering that there are not much changes between foxy and master, should both be unified?
In that case, this fix is required, as I have broken compatibility in #192.

Before unifying branches, it should be double checked if #187 is completely backwards compatible.

PS: We usually create branches in other repos during the release process, thus one was "automatically" created here in the release process.

[eboasson]

@ivanpauno, now that all features are supported, there is not much point in maintaining compatibility with all versions in the RMW layer. As long as it is easy to do so (like here), there is still some value in it, but when the differences become larger (like with the node-to-participant mapping change) it is not worth it.

Once there is a Cyclone 0.7.x branch (which will include security), there will also no longer be a need to track Cyclone master. So from that point on everything will be "normal".

[ivanpauno]

@ivanpauno, now that all features are supported, there is not much point in maintaining compatibility with all versions in the RMW layer. As long as it is easy to do so (like here), there is still some value in it, but when the differences become larger (like with the node-to-participant mapping change) it is not worth it.

Sure.
I opened this because I wasn't sure if the foxy branch was created by mistake or if it is intentional to maintain different versions from different branches now.
In the former case, I wanted to make sure I didn't break compatibility in master unintentionally 😁 .

@eboasson feel free to merge or close, depending if foxy/master branches are going to be unified or not.
I'm not an usual maintainer of this package, so I don't have a preference.

[jacobperron]

I opened this because I wasn't sure if the foxy branch was created by mistake or if it is intentional to maintain different versions from different branches now.

I think I was the one who created the foxy branch in a batch process. It wasn't necessarily a mistake, as I expected ABI to diverge at some point and wanted to have an ABI-stable version for Foxy. Considering that master is several releases ahead of foxy, I'm not sure that we should switch to using master for Foxy (I haven't looked closely at possible ABI changes).

[eboasson]

Let's stick to the "standard" model, so keep using the foxy branch that @jacobperron made during Foxy release and master for the current development. In the past, keeping a single branch meant that Dashing and Eloquent ended up with full coverage of features. Foxy is already fully supported by the foxy branch, and in my view, that means the extra work (and risk) of maintaining compatibility no outweighs the benefits.

Closing as suggested by @ivanpauno.

[rotu]

in my view, that means the extra work (and risk) of maintaining compatibility no outweighs the benefits.

@eboasson, that should probably be documented. Adding a backwards incompatibility should be accompanied with a bump of the major version number. Using the branch as the de-facto major version number is a terrible habit.

[eboasson]

@rotu while I agree in general, as I understand it, that's the common practice in ROS 2 packages. The rmw_cyclonedds_cpp package is purely an adaptation thing for ROS 2, so conforming to the development/branching/versioning policy of ROS 2 only makes sense.

Cyclone DDS itself is a different story, that one has an independent life, has a stable interface and maintains backwards compatibility.