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

[Carlos J Rosales Gallegos]

Hi, it seems like the right discussion to expose something that has always been on my mind. Not about the rolling release schedule, but how these releases are developed and maintained using `git`. I'm not super expert on the matter, and not seeing anyone say anything about it makes me think I might be wrong or not seeing the obvious. But hey, you never know, so here are is my concern.

I've always found the ROS branching-per-devel, and accepting development on those branches, philosophy kind of poor regarding guarantee new features and bug fixes in new releases. Let me explain why.

I myself (remember, not being a super expert), found a missing feature in releases ahead that was available in previous releases. Here is the issue: https://github.com/ros/ros_comm/issues/575 If you follow the issue, there was timing issue between accepting a PR and creating a branch for a new release. In fact, you can see Dirk Thomas in the end adding commits manually in order to have the feature in subsequent releases. Which I don't know for you, but to me it seems kind of awkward, right? I mean, having to cherry-pick or merge features into future releases does not sound good to me in general (there might be rare situations though). Luckily it was a not-critical thing, but what if it were? Whence my concern.

So I wonder: Why most of ROS development don't use a unique branch, say `master` or `unstable` or `default`, where you mostly accept PRs for new features and bug fixes, and then tag releases from there with any of the suggested rolling schedules proposed above, (or even branch from there, if you like a release-per-branch style to cherry-pick compatible bug fixes and features into previous releases)? This way, you guarantee all new features and bug fixes will be available in every new release since they are in a single development branch. At the same time, this is a bit of a push for people to update to new releases in order to get an improved and cleaner version of the software, as well as reducing efforts for maintainers in keeping track of new code being added for new releases IMHO.

Anyone sharing the same concern or with any reason why this is not a good practice?





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