[ros-users] [Discourse.ros.org] [General] Proposed changes to the ROS releases

Carlos J Rosales Gallegos ros.discourse at gmail.com
Fri May 11 17:25:57 UTC 2018

Thanks for your reply. I understand the point of the requirements of each package.

[quote="dirk-thomas, post:9, topic:4736"]
aim for stability since every code change has the potential to introduce regressions

Precisely my point, why do you need to put efforts in regression of those changes? Unless you want to be stable in all distros, which can also be potentially hard to achieve anyway, right?

Perhaps this scheme clarifies both my concern and my suggestion:

Currently in most of ROS repositories (comm and leaves):
           C5 <- C6 <- C7 <- [melodic]
  C3 <- C4 <- [lunar]
C1 <- C2 <- C3 <- [kinetic]

For some reason, the bug fixed C3 was accepted in `kinetic`, but then cherry-picked/merged into `lunar` manually, that is, into a future release. So `melodic` and `lunar` will have a bug fixed that was manually added. But, `melodic` will have it only if the branching took place after C3 on `lunar`, otherwise it needs to be added manually too.

My suggestion would be (release-per-branch or tags, but keeping a single line of development):
  C3 <- C6 <- [kinetic]    [lunar]     [melodic]
 /                        /           /
C1 <- C2 <- C3 <- C4 <- C5 <- C6 <- C7 <- [master]

Where C3 is still a bug fixed, and add C6 if you want, merged into a _previous_ release, namely `kinetic`. These fixes do not need to be manually added to either `lunar` and/or `melodic`, since they will have them by construction.

Correct me if I'm wrong, but wouldn't the later makes it easier and safer to maintain for both comm and leaf packages? And still comply with both goals, have new features for new releases and still able to deal with regression stability?

Side note: Just interested in your points of view as a consumer of comm packages and developer of leaf ones.

[Visit Topic](https://discourse.ros.org/t/proposed-changes-to-the-ros-releases/4736/10) or reply to this email to respond.

More information about the ros-users mailing list