mark YUV encodings as deprecated

[christianrauch]

#214 introduced new encoding names uyvy and yuyv as replacement for yuv422 and yuv422_yuy2. This PR marks those replaced encodings as deprecated with a hint which encoding to use instead and removes their usage in this repo.

[tfoote]

Marking these as deprecated I think makes sense, but we need to have a transition time before they are removed from the implementation as removing them from the implementation will break any current users. The cost of keeping these is moderately low so we should consider a moderately long deprecation cycle. More than just the minimum one release cycle.

[christianrauch]

The CI marks this as "unstable", probably because there are 6 new warnings (https://build.ros2.org/job/Rpr__common_interfaces__ubuntu_noble_amd64/24/gcc/new/) from the "deprecated-declarations" that are introduced by this PR. @tfoote I guess keeping on using the deprecated encodings is not an option anymore?

[tfoote]

You need to explicitly suppress those warnings that are known to the developer for backwards compatibility.

https://stackoverflow.com/questions/13459602/how-can-i-get-rid-of-deprecated-warnings-in-deprecated-functions-in-gcc

Luckily clang will pick up the GCC ones

https://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-via-pragmas

[christianrauch]

I wrapped the code that is still using the deprecated marked encodings inside the GCC diagnostic pragma:

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
[...]
#pragma GCC diagnostic pop

[christianrauch]

@tfoote Can you have a look at this again?

[tfoote]

Thanks for taking the time to mark these as deprecated. This will be helpful going forward. The change looks good. Sorry for the high latency, I'm on leave at the moment. I will come back to this for merging when I'm back in the office to avoid disruptions when I can't pay close attention unless someone else gets to it sooner.

[christianrauch]

@tfoote Is now a good time to have a look at this? :-)

[clalancette]

Please make sure to run CI on these PRs; this one has caused regressions.

[clalancette]

Besides causing warnings on all platforms, the pragmas used here for GCC do not work on Windows. I'm going to revert this commit, because it causes too many problems right now.

[christianrauch]

Please make sure to run CI on these PRs; this one has caused regressions.

The CI on this PR passed (https://build.ros2.org/job/Rpr__common_interfaces__ubuntu_noble_amd64/27/).

Of course, this CI does not test other repos and as far as I understood, causing warnings such as warning: ‘sensor_msgs::image_encodings::YUV422’ is deprecated: use sensor_msgs::image_encodings::UYVY is expected and was the reason to deprecate the encodings before they are removed.

If we do not deprecate them before removal, how can I proceed with this? If the CI in this repo is not sufficient, how do we know if a PR can be merged?

[clalancette]

Of course, this CI does not test other repos and as far as I understood, causing warnings such as warning: ‘sensor_msgs::image_encodings::YUV422’ is deprecated: use sensor_msgs::image_encodings::UYVY is expected and was the reason to deprecate the encodings before they are removed.

We do not allow warnings in the core. So if something is deprecated here, we need to update the rest of the core that depends on it. Additionally, the #ifdef guards here did not work on Windows, and caused additional regressions there.

If we do not deprecate them before removal, how can I proceed with this?

We should deprecate them before removal.

If the CI in this repo is not sufficient, how do we know if a PR can be merged?

We have CI jobs (which you can see in #256 (comment)) which do test PRs against the entire core. Those need to be run before we merge anything in (we do that for all PRs).

[christianrauch]

We have CI jobs (which you can see in #256 (comment)) which do test PRs against the entire core. Those need to be run before we merge anything in (we do that for all PRs).

Are those triggered automatically for PRs to this repo? If so, this did not happen last time. If not, how do I trigger this for a new PR?

[clalancette]

Are those triggered automatically for PRs to this repo?

No, they need to be manually run by a maintainer.

[christianrauch]

Ok. I guess I will then run those locally for now and will ask again once I submit a PR again.

For this deprecation change to be accepted again, is it sufficient if all of https://github.com/ros2/ros2/blob/rolling/ros2.repos builds on Linux and Windows without warnings?