Naming Convention for ROS 2 repositories

Next Generation ROS
1

I could have sworn that I saw someone else post this question but I can’t for the life of me find it.

My question is - if we are developing packages for ROS 2 should we:

A) make a dashing-devel branch within the repo that was used for ROS 1
B) make a new repo and name it my_driver_ros2 and rename the old repo my_driver_ros1

I’d like to hear what the Open Robotics folks have to say about this. It would be really nice if everyone did the same thing.

2 Likes
2

Yeah, I last posted on that back in December, here. I think the advice there still holds; if the port shares substantial code with the ROS 1 code, then a branch makes sense. If it is a ground-up rewrite + port to ROS 2, a separate repository makes sense.

3

If the ROS1 and ROS2 versions share a substantial amount of code, I would recommend to move this into a dedicated <my_driver> library and have thin <my_driver>_ros1 and <my_driver>_ros2 wrappers.
See also: ROS2 Transition Strategy

4

I think even for a total re-write adding it as a branch would make the most sense for sorting and keeping URLs intact. Having some packages appended with 2 and others as branches makes things very confusing and frustrating.

5

Great, thanks for the link @clalancette. I agree that not breaking links is important, I just don’t like that devel branches are used for releases, but I can live with compromise. We will be changing our repo to conform to the “one repo for both ROS 1 and ROS 2 with melodic-devel and dashing-devel branches” standard.

6

Just for context: the -devel suffix in the branch names is mostly for historic reasons. When we started using branches for each distro the repositories also had tags named by the ROS distro (e.g. groovy) and therefore the branch named needed to be different.

By now tags are commonly using the version number so you could consider dropping the -devel suffix…

2 Likes
7

@smac which URLs are you referring to keeping intact? The thought of managing two separate codebases through (orphaned) branches in a single repository isn’t sitting well with me – I’d much prefer seperate git repos for separate ROS/ROS2 projects, even though they’ll share the same package name in the index.

But if there’s some strong reason to do so to ‘play nice’ with the rest of the ROS tooling and documentation I’ll consider it.