Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add deprecation messages to all messages now in example_interfaces #116

Merged
merged 2 commits into from
May 18, 2020

Conversation

tfoote
Copy link
Contributor

@tfoote tfoote commented May 18, 2020

Followup to #89

Followup to #89

Signed-off-by: Tully Foote <tfoote@osrfoundation.org>
Copy link
Contributor

@hidmic hidmic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder about the rationale behind deprecating what's in std_msgs and moving it to example_msgs. It's been like this in ROS 1 for over a decade, why the change?

@@ -1,3 +1,8 @@
# This was originally provided as an example message.
# It is deprecated as of Foxy, it is recommended to create your own
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tfoote consider

Suggested change
# It is deprecated as of Foxy, it is recommended to create your own
# It is deprecated as of Foxy.
# It is recommended that you create your own

same elsewhere.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks that reads better, updated.

@tfoote
Copy link
Contributor Author

tfoote commented May 18, 2020

It's been in ROS 1 that we generally recommend against using almost any message in std_msgs except Header for a long time for stability.
From the Overview: http://wiki.ros.org/std_msgs

However, these types do not convey semantic meaning about their contents: every message simply has a field called "data". Therefore, while the messages in this package can be useful for quick prototyping, they are NOT intended for "long-term" usage. For ease of documentation and collaboration, we recommend that existing messages be used, or new messages created, that provide meaningful field name(s).

Note that this package also contains the "MultiArray" types, which can be useful for storing sensor data. However, the same caveat applies: it's usually "better" (in the sense of making the code easier to understand, etc.) when developers use or create non-generic message types (see discussion in this thread for more detail).

However from the naming it leads to a lot of confusion.(For example) And we want to take the opportunity in ROS 2 to avoid that ambiguity. The earlier we do it in this cycle the easier and less disruption it will cause.

Signed-off-by: Tully Foote <tfoote@osrfoundation.org>
@tfoote tfoote self-assigned this May 18, 2020
Copy link
Member

@jacobperron jacobperron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Though their usage has been discouraged for a long time now, it might be worth highlighting that we have "officially" deprecated them in the Foxy release notes.

@jacobperron
Copy link
Member

I guess we shouldn't have run CI for this change since it caused a test failure downstream: https://ci.ros2.org/view/nightly/job/nightly_linux_release/1548/testReport/ros2interface.src.ros2.ros2cli.ros2interface.test/test_cli/test_cli/

See a fix in ros2/ros2cli#516

@ros-discourse
Copy link

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

https://discourse.ros.org/t/soss-a-whole-new-approach-to-your-ros-1-ros-2-bridge/17040/18

@ros-discourse
Copy link

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

https://discourse.ros.org/t/discussion-standardizing-ros-interfaces/33693/1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants