[infinispan-dev] Branching proposal

[Galder Zamarreño]

Why are we working in 9.1.x, 9.2.x and master in paralell? We normally work on master and maybe one more maintenance branch.

Except for occasional tricky backports (e.g. Radim's work) the rest has been pretty straightforward for me. Also, the number of backports I work on is low in general.

Cheers,
--
Galder Zamarreño
Infinispan, Red Hat

> On 27 Mar 2017, at 11:33, Sebastian Laskawiec <slaskawi at redhat.com> wrote:
> 
> 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
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev