I’m interested in initiating a discussion on the benefits and potential drawbacks of setting the package’s default development branch to rolling instead of the traditional main (or master or ros2 ). This topic aligns with the conversation started in the following thread: Change Default Branch Name to Rolling in ROS 2 Core. I’d appreciate insights and perspectives from the community on this matter.
From my point of view:
Cons:
It is not usual in non-ROS projects.
Pros:
It is clear which distro is used to build the default branch.
If you have a periodic CI, you are ready to create the branch for each distro as soon as it is released.
Do you see any more pros or cons? Do you think this can become a general recommendation?
They are harder to maintain. Bug fixes, new features, and functionality must be duplicated for each release branch.
They are harder to learn and master as they require a higher software engineering discipline to apply correctly and sustain.
My general recommendation, unless the package is tightly integrated with a core ROS functionality, is to go with trunk-based development (single main branch, frequent/small updates). You better architect the core of your robotic package as a native library in your programming language inside their ecosystem. Then, bind it with ROS releases (or other pub-sub libraries) as late as possible. This would improve robustness, testability, and maintainability.
I think rolling makes sense if you really are branching for every rosdistro - but I’ve found that often isn’t entirely required.
For a number of my own projects, I’ve stuck with having a default ros2 branch which covers pretty much all the recent/supported distros (in most cases, I need a separate branch for old distros like Foxy, but can cover everything newer with the same branch). In many cases, my
same repo also has an older, and pretty much unmaintained at this point, ros1 branch.
Plus, whenever you look at that ros2 branch name, you get to giggle a little that there is no space between ros and 2.
I think about each of these as being largely interchangable. I wouldn’t be opposed to a more official policy (Fergs’ makes much sense). Its not something that keeps me up at night, but if there was a concern we could address with more consistency, I’m all for it!
Honestly - the best “policy” here for things outside the very core ROS is probably just to document what you’re doing. For released packages, index.ros.org will tell you which branch should work for which distro (although, I’m not sure the beginner docs really highlight how to use index.ros.org).
Putting a note about branching conventions near the top of the README of the git repo can also be beneficial. I used to do this all the time back in the ROS 1 days when we did things like indigo-devel works for indigo & kinetic, then we branched to melodic-devel for melodic and noetic, and hey there is an experimental ros2 branch too.
