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

[Carlos J Rosales Gallegos]

Hi all,

Motivated by the discussion I started [here](https://discourse.ros.org/t/proposed-changes-to-the-ros-releases/4736/8?u=carlosjoserg), or similar threads like [this one](https://discourse.ros.org/t/upcoming-change-on-branching-strategy/1009), I'm gonna fire this thread.

First of all, I reckon that a maintainer chooses the way that best fits his/her needs to maintain a repository. So I'd like to avoid pointing at particular cases where something's happened or not, how often or not... I rather have a discussion regarding pros and cons of git branching strategies within the ROS community practices.

Currently, in most of ROS repositories, one sees this approach:

```
           C5 <- C6 <- C7 <- [melodic-devel]
          / 
  C3' <- C4 <- [lunar-devel]
 /
C1 <- C2 <- C3 <- [kinetic-devel]
```

Where a new _development_ branch is created for every _release_ candidate. That requires the maintainer to create this branch, and be aware of the latest branch created to accept PRs or continue developing.

The most critical thing to me is that, newer releases are not guaranteed to have bug fixes / new features. For instance, in the figure above, if `C3` gets accepted on `kinetic` for any reason, then it needs to be manually _forward_ ported to `lunar`, that is, from an older version to a newer version, which does not seem right. No matter how often this might happen, there is the possibility that it might.

Another minor issue is, I think in some repositories the branch is created only if there is a change to make and there is a new available release, or even because the maintainer just stopped creating branches. In that case, if a repository has not changed since, say `hydro`, and no one has PRed since, then usually the latest branch in the repository is that one, even when the same version of code exist for, say `melodic`, via apt-get, which doesn't seem right either or might lead to confusion.

An alternative would be:
```
  C3' <- C6' <- [kinetic]    [lunar]     [melodic]
 /                        /           /
C1 <- C2 <- C3 <- C4 <- C5 <- C6 <- C7 <- [master]
```
Where there is a _single development line_, say `master`, `devel`, or `unstable`, something you readily identify as the branch to target PRs to by default for new stuff. Maintainers still need to tag / branch for a new release, but at least they don't need to worry about which is the _latest development_ branch and coordinate PRs.

A small big difference about this strategy w.r.t. the one before is that, if `C3` is again a bug fix, newer releases will have it _by construction_, no need to be aware of any latest branch to accept PRs, or wait for a branch to be created because it's better to target it to the a newer release. Development and releases are decoupled this way. Moreover, one can still back port to older releases, and if it happens that one needs more work to do that, one can still add stuff to older release branches. The concept of pre-release tags is clearer to use in this strategy too.

For the record, I know this is not a new idea, there are a bunch of repositories out there being maintained like this, hence the motivation of the post, it makes me wonder why most of ROS repositories choose the first strategy.

Any thoughts?





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