[infinispan-dev] Branching proposal

[William Burns]

On Tue, Mar 28, 2017 at 9:27 AM Galder Zamarreño <galder at redhat.com> wrote:

> 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.
>

+1 For me the hard part is just remembering it needs to be backported. And
as Sanne mentioned refactorings shouldn't really be backported and these
are the types of the things that cause the most conflicts. And to be honest
on some backports I might not pull every change since the real fix may have
been quite small.


>
> 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
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170328/017f8229/attachment.html