Re: [boost] question/guidence regarding merge to master

Subject: Re: [boost] question/guidence regarding merge to master
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2019-01-11 08:17:20

On Fri, 11 Jan 2019 at 06:05, Robert Ramey via Boost
<boost_at_[hidden]> wrote:
> On 1/10/19 6:58 PM, Peter Dimov via Boost wrote:
> > Robert Ramey wrote:
> >> I'm looking to merge my develop branch into the master so that they
> >> will be in sync.  I'm thinking that this the changed in develop should
> >> be squashed so that the master branch doesn't included all the the
> >> intermediate changes made during the develop phase.  Is there any
> >> boost rule/practice/guidence regarding this?.  Ideally, I'd like to
> >> see the master have only one set of consolidated changes for each
> >> release.  But I'm not the person who decides these things or does the
> >> work.  Any insight by other parties would be appreciated.
> >
> > My guideline is:
> >
> > - work that has passed local tests goes into a feature branch
> > - feature branches that have passed CI go into develop
> > - develop that has not broken anything goes into master
> >
> > That is, develop is not a place for experimentation (or, ironically
> > stated, develop is not for development). The squashing, if needed,
> > happens on the merge from the experimental feature branch into develop,
> > not on the merge from develop to master. Ideally, the merge from develop
> > to master is fast-forward and the two contain the same commits, with
> > master just trailing behind.
>
> Hmm - but then when the CI fails on develop and a few more tweaks are
> necessary basically to deal with compiler/ci vagaries, this cruft then
> ends up on the master history.

There is possibility that infrastructure stuff is different in master
vs develop,
or minor maintenance of build scripts and tweaks go into develop directly.
Such exception to Peter's is not uncommon.
It's also possible tweaks go into master only
But, since Boost does GitFlow, master is never merged into develop,
so it should not be a problem for merges in the reverse direction.

> Also, then shouldn't master just be just a tag into the the last passing
> develop branch?

Are  you suggesting departure from GitFlow, or has it already happened?

> I do think it would be useful for someone to "codify" these practices
> because a lot of don't know (and don't really want to know) and don't
> really care which practices to follow and would be happy to follow
> whatever someone who spends time with this stuff has concluded would be
> the best way.

I'd be happy to learn myself too.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net