On Wed, Sep 30, 2015 at 5:09 PM, Brian Gerkey via ros-users
<ros-users@lists.ros.org> wrote:
> We're very aware of the need for a migration plan.  To that end, we're
> maintaining a migration guide as we do new development:
>   http://design.ros2.org/articles/migration_guide_from_ros1.html

That guide is a nice overview of the migration of a hello-world node.
So let's list what is missing from this migration example:

- workspace setup (ament)
- service C++ API
- dynamic_reconfigure
- nodelet
- paramserver params
- launchfiles (*)
- rostest
- wiki article
- wiki tutorials
- sphinx docs
- bloom
- change of provided message/service structure
- change of consumed message/service structure
- python API change
- other languages (C/Lisp/Java)
- Python3 (*)
- Environment setup files
- ABI versioning
- QoS configuration
- Any custom scripts relying on any of rospkg, rosrun, rosnode,
rostopic, rosparam, roslaunch
- Adapting to various structural changes in dependencies

parallel maintenance:
- package naming
- parallel wiki entries
- parallel wiki tutorials
- double bloom releases

interoperation
- document how this ros1 package interops with ros2 packages
- document how this ros2 package interops with ros1 packages
- launchfiles (bridge nodes for each topic and service)
- rostest files to test interop
- workspace setup (catkin over ament)
- Additional bridge mappings for changed message structures

Then there is the topic of cross-compatible code that will probably emerge
- code littered with #ifdef's
- using some ros/ros2 abstraction library
- cmake hacks to make cmake work in both ament and catkin
- python hacks to make setup.py work in both ament and catkin

(*) mentioned in guide not in example

>> Intentionally quoted out of context:
> It's likely that those changes could be largely automated, at least
> for simple cases.

For simple cases, indeed.
_______________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users