[infinispan-dev] Branching proposal

[Radim Vansa]

If you can't merge a commit (based on 9.0.x) to master clearly, do you 
need to file another PR anyway? Then the lag to get some code to master 
increases a lot. I am not sure how useful is git tag --contains <sha1> 
if you cannot be sure that you'll find all occurrences due to this kind 
of issues.

R.

On 03/27/2017 11:33 AM, Sebastian Laskawiec 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


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team