[infinispan-dev] Branching proposal

[Sebastian Laskawiec]

Hey!

We are about to start working on 9.1.x and 9.2.y branches so I would like
to propose alternative merging strategy.

Our current workflow looks like this:

X - new commit
X` - cherry pick to maintenance branch
--+-------------------+-------X----- master
  |                    \------X`---- 9.2.x
  \---------------------------X``--- 9.1.x

Each commit needs to be reviewed in master branch and backported to the
maintenance branches. From maintenance perspective this is a bit painful,
since in above example we need to get 3 times through PR queue. Also it's
worth to mention that X is not X` nor X``. Cherry-picking creates a copy of
a commit. This makes some useful tricks (like git tag --contains <sha1>) a
bit harder to use. Finally, this approach allows the codebase to diverge
from maintenance branches very fast (someone might just forget to backport
some of the refactoring stuff).

The proposal:

X, Y - new commits
/ - merge commits
--+---------+------/----/--- master
  |          \----/---Y/---- 9.2.x
  \-------------X/---------- 9.1.x

With the proposal, a developer should always implement a given feature in
the lowest possible maintenance branch. Then we will run a set of merges
from 9.1.x into 9.2.x and finally into master. The biggest advantage of
this approach is that given functionality (identified by a commit) will
have the same SHA1 for all branches. This will allow all tools like
(mentioned before) `git tag --contains <sha1>` to work. There are also some
further implications of this approach:

   - Merging commits should be performed very often (even automatically in
   the night (if merged without any problems)).
   - After releasing each maintenance release, someone will need to do a
   merge with strategy `ours` (`git merge -s ours upstream/9.2.x`). This way
   we will not have to solve version conflicts in poms.
   - Since there is no nice way to rebase a merge commit, they should be
   pushed directly into the master branch (without review, without CI). After
   the merge, HEAD will change and CI will automatically pick the build.
   Remember, merges should be done very often. So I assume there won't be any
   problems most of the times.
   - Finally, with this approach the code diverges slight slower (at least
   from my experience). Mainly because we don't need to remember to
   cherry-pick individual commits. They are automatically "taken" by a merge.

>From my past experience, this strategy works pretty nice and can be almost
fully automated. It significantly lowers the maintenance pain around
cherry-picks. However there is nothing for free, and we would need to get
used to pushing merged directly into master (which is fine to me but some
of you might not like it).

Thanks,
Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170327/f05f5456/attachment.html