I wrote a post in the ros-planning GitHub discussions page to address the common question of “Which version of ROS and MoveIt should I be using with my project?” from the perspective of how MoveIt as a project approaches this problem.
I would appreciate feedback if you have a different approach to solving this problem for your projects. In many ways, this is my understanding of how I should be working and how I can best help MoveIt be useful.
Some projects have taken more or less liberty with the stability of ROS releases they bloom into. This has caused us some frustration, and it would be wonderful if the larger community of open-source ROS projects could agree on an approach to stability and feature development.
main, ros2, rolling branch is for bleeding edge development and while we try and often do keep it stable, the purpose of it is the main development and as a result its going to be the highest risk of branches
distribution branches (humble, iron, etc) are branched off the bleeding edge at the freeze and released. From that point on, ABI/API compatibility is retained and backports from main are made for syncs only when compatible, not fundamentally changing default behavior, and able to be merged without significant merge conflicts
I expect that for (1) any particular but arbitrary company which has (2) knowledgeable developers and are interested in maintaining their own system to add internal changes + (3) absorb some of bleeding edge they want, the right answer is to maintain a branch off of their own distribution of use and pull in changes from main, even when they break ABI/API if they know they want to use it. Since they know how they use the API/ABI, they know which changes don’t actually impact them. Even when breakages occur, they can intentionally own the upgrade process at that time to make use of it.
That last point only works for particular but arbitrary organizations because I cannot generically tell every company what parts of ABI/API stability are important to them and which aren’t. However if you know for your particular instance what matters and what you care about, you can ingest more changes than would be appropriate for me to push to you.
However, its still recommended to develop changes on main and backport later to your distribution branch so that you can keep in sync with the bleeding edge and make sure you don’t box yourself into a corner requiring a hard fork – since you’re taking changes from main later on. Keep the development flow in a single direction globally and you can save yourself alot of suffering.
While not required, it also facilitates far easier contribution of your new feature or bug fixes back to open-source, which I highly encourage. The less you need to personally maintain, the better, and the more that’s available for others to play with, the reduced risk you have. Its a win-win-win for yourself, the project, and your fellow developers. I’d always rather you give me a patch that fixes a problem or implements a feature but you’re under constraints and are unable to reach the quality level that we require to merge it. I can do it or find someone that will! If you have something to give back, we’ll always find a way to make it work. Though always best if you can do yourself, I only have so many waking hours
I think your third point is one that I worry about just turning into a long-running fork that can never be brought back upstream. I’ve seen that happen a few times and generally discourage it. In some ways, this seems like the Google way of working, where you fork the whole world. That approach works for Google because they have the money to afford it. It is easy to make a fork, and the longer it lives, the harder it is to ever escape it (either to accept changes from upstream or to contribute changes upstream).
I don’t think most users do that, just the power users. The power users are also the ones most likely to contribute back so overall I think its quite successful as long as its paired with proactive and rapid maintenance. If you make people wait a week for a review or comment, its unlikely they’ll come back with more. If you respond so that the fix is in the stack and no longer on their fork to maintain within a week or two, they’re motivated by selfish desire to get it out of their court and into yours
I agree with the pain of long-running branches, but unfortunately it’s a necessary evil as several bug fixes are not backported to old distributions (e.g. if they break API/ABI and are not trivial to reimplement) or we just can’t wait for the backport.
Moreover, we want to minimize unnecessary changes: from one sync to another a package like rclcpp may change in a substantial way, thus requiring a large testing effort (much larger than if we maintain a fork and we cherry-pick a single, small, commit with a bug fix and nothing else).
In terms of contributions, I don’t think that the “forks approach” necessarily slows them down.
The main issue here is whether companies are able to stay up to date with the latest ROS distribution or not (if not, you end up having to maintain two versions of a feature: one internal for distribution X and one for a PR targeting distribution Y)
