Closed bionade24 closed 5 years ago
How did you fix this?
I believe I wrote this once in a mail, that some of the packages under ROS1 github group with a 2.x release are for ROS2. So we have to choose the 1.x Releases. They're still both versions in development, at some packages you can see 1.x updates after 2.x was updated. So just stay with 1.x releases, I was just silly and believed that everything under ROS is for ROS1
You did say that. I just thought ROS1 = 1.x and ROS2 = 2.x for the versioning. For this package, how do you identify which is ROS1 vs. ROS2, as there is no 2.x in releases? Is it 0.x vs. 1.x?
Probably yes. Will try it when I'm at home.
Did you check on this and how to tell ROS1 vs. ROS2? Is it always the lowest major version number (e.g. 0 or 1) vs. the higher (1 or 2)?
I only had the case where it was the lower one, but I'll ask.
class_loader in ROS 1 will likely always occupy the 0.x version space. Versions greater than 1.x are being used for ROS 2. There is a possibility that the class_loader codebase for ROS 1 and ROS 2 may unify in time.
When choosing class_loader releases you should check the ROS distribution you are targeting and use the same version. For example here is the class_loader entry for Melodic on the ROS index https://index.ros.org/p/class_loader/github-ros-class_loader/#melodic which specifies the currently released version 0.4.1.
But, e.g. pluginlib uses 1.x and 2.x releases. So it's always the lower number for ROS1, isn't it?
But, e.g. pluginlib uses 1.x and 2.x releases. So it's always the lower number for ROS1, isn't it?
The only thing you should be relying on is what the ROS distribution reports. Any other heuristic is not guaranteed even if it may not ever be incorrect.
Ok. When we fetch the correc version from the API of index.ros.org, it shouldn't be a problem.
Latest relase of this package, ros-melodic installation.
Same issue with other package: https://github.com/ros/ros_environment/issues/15