image_transport_plugins: 3.0.0-1 in 'rolling/distribution.yaml' [bloom]

[ijnek]

Increasing version of package(s) in repository image_transport_plugins to 3.0.0-1:

• upstream repository: https://github.com/ros-perception/image_transport_plugins.git
• release repository: https://github.com/ros2-gbp/image_transport_plugins-release.git
• distro file: rolling/distribution.yaml
• bloom version: 0.11.2
• previous version for package: 2.6.0-2

compressed_depth_image_transport

* Replace deprecated cv_bridge.h with cv_bridge.hpp (#118 <https://github.com/ros-perception/image_transport_plugins/issues/118>)
* Update maintainer (#112 <https://github.com/ros-perception/image_transport_plugins/issues/112>)
* Contributors: Kenji Brameld

compressed_image_transport

* Deprecated the following parameter names in favor of transport scoped ones. The remapping is listed below:
  * image.format to image.compressed.format
  * image.png_level to image.compressed.png_level
  * image.jpeg_quality to image.compressed.jpeg_quality
  * image.tiff.res_unit to image.compressed.tiff.res_unit
  * image.tiff.xdpi to image.compressed.tiff.xdpi
  * image.tiff.ydpi to image.compressed.tiff.ydpi
  The deprecated parameters emit a warning if explicitly set, but this warning will be removed in future distros.
  (#143 <https://github.com/ros-perception/image_transport_plugins/issues/143>)
* Replace deprecated cv_bridge.h with cv_bridge.hpp (#118 <https://github.com/ros-perception/image_transport_plugins/issues/118>)
* Update maintainer (#112 <https://github.com/ros-perception/image_transport_plugins/issues/112>)
* Compressed image transport parameters are now reconfigurable (#108 <https://github.com/ros-perception/image_transport_plugins/issues/108>)
* Contributors: Bartosz Meglicki, Ivan Santiago Paunovic, Kenji Brameld

image_transport_plugins

* Update maintainer (#112 <https://github.com/ros-perception/image_transport_plugins/issues/112>)
* Contributors: Kenji Brameld, Michael Carroll

theora_image_transport

* Replace deprecated cv_bridge.h with cv_bridge.hpp (#118 <https://github.com/ros-perception/image_transport_plugins/issues/118>)
* Update maintainer (#112 <https://github.com/ros-perception/image_transport_plugins/issues/112>)
* Contributors: Kenji Brameld, Michael Carroll

[ros-discourse]

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/preparing-for-iron-branching-on-rolling-2023-04-18/30980/2

[ijnek]

Thanks @clalancette

[ijnek]

Hi @clalancette, there was an API change in this release that changed the parameter names in compressed_image_transport to be scoped by the image transport name (and hence the major bump).

Unfortunately, these API changes were made only to compressed_image_transport, but the matching changes that should have been made in theora_image_transport and compressed_depth_image_transport are not yet implemented. This means the parameters aren't scoped for those transports. Although things compile and work, the partial API change would be potentially confusing to users. (I regret trying to rush and get a release in for Iron).

Is is too late to make a new release (2.6.1) that removes this API change, but retains the other non-API breaking improvements?

[clalancette]

Is is too late to make a new release (2.6.1) that removes this API change, but retains the other non-API breaking improvements?

No, it's not too late. We will accept updates to Rolling and Iron up to May 18th (though things are frozen right now, so any release you do at the moment won't be merged until next week).

That said, you may want to carefully consider your version numbers. Because these packages have successfully built, the 3.0.0 release is already available via the ros2-testing repository. While that is a testing repository, and you are allowed to revert things out of it, anybody who has done an apt-get upgrade from it will now be at 3.0.0. If you do a new release of 2.6.1, they will not get upgraded.

Instead, my suggestion is that you revert the problematic change, and call it 3.1.0 (or whatever). When you eventually want to put that change back in, you merge it and call the new release 4.0.0. But this is completely up to you; if you'd rather go back to 2.6.1, that is allowed.

One last thing to note is that whatever you do here, you'll have to do new releases for both Rolling and Iron (since we just branched Iron off).

[ijnek]

Thanks for your response @clalancette.
I guess there is no specific date for API/feature freeze for packages list in REP-2001 that aren't in the Iron release timeline..
If that's the case, since there is a bit more time, we will see if we can get the changes implemented across all of the plugins and release them both into Iron and Roling.

Thanks for the tip on the version numbers, too!

[ijnek]

Release was made into iron with all the transports' parameters deprecated and replaced by the new ones - #37153