[ros-users] [Discourse.ros.org] [Quality Assurance] On (git) branching strategies

[Daniel Stonier]

I've been maintaining repositories for quite a while in the ROS world and have had my perspective change considerably. A big part of that is just reducing scope to that which I can practically and reliably maintain / document. That's kind of taken me full circle back to a very regular devel/release style:

1. Only ever one 'devel' branch, all other branches are releases
2. The README in the devel branch communicates what distro it is currently (unofficially) supported on
3. Bugfixes only on release branches, PATCH version bumps only, always tag every version
4. Reflect the distro it is used on in the name of the release branch
5. Reflect the MAJOR.MINOR version number in the name of the release branch as well

I find this communicates the purpose of each branch effectively with minimal fuss. People know then where and what they should PR to (features to devel, bugfixes to the release), what distro they need for any branch (no need to document). They can also quickly grokk when feature changes occur across distros - don't bump your version just because the distro bumped. Another key point is that the root url to anything in your repo will never change (as it would if you changed your default branch to <distro>-devel for every ros release).

Example:

    devel
    release/0.6-kinetic
    release/0.7-lunar-melodic

One downside with this is that you can't support users who wish to contribute features for a distro that you've already moved on from (i.e. not supported by 'devel'). At the end of the day though, supporting that is complicated, prone to error and there are good reasons in the software world why this is rarely done (be sure you have the cycles to do so).





---
[Visit Topic](https://discourse.ros.org/t/on-git-branching-strategies/4785/6) or reply to this email to respond.