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

Subject: Re: [boost] question/guidence regarding merge to master
From: James E. King III (jking_at_[hidden])
Date: 2019-01-11 17:28:49

On Fri, Jan 11, 2019 at 10:26 AM Andrey Semashev via Boost <
boost_at_[hidden]> wrote:

> On 1/11/19 6:21 PM, Robert Ramey via Boost wrote:
> > On 1/11/19 7:16 AM, Andrey Semashev via Boost wrote:
> > \
> >> To illustrate, just the other day I had to track down a change in
> >> Boost.Filesystem so that I could tell a user when a bug appeared in
> >> the code and when it was fixed. I was able to do that, both in terms
> >> of Boost realeases and commits with their respective commit messages
> >> and dates, because I had a fine grained history with tags. I was able
> >> to track down the particular PRs, if I had to. I think, this is an
> >> important feature of the detailed git history.
> >
> > Right - but couldn't you have done that with the develop History?
>
> No, because release tags are applied to the commits in master that are
> used to ship a Boost release.
>
>
Actually, yes, since if you do what I said before and ensure all merges from
develop to master are fast-forwards, then the tag applies to a hash which
exists in master and develop.

The main purpose of having master and develop is that the boost project
does not use separate release branches per release, just master.

Robert, I see your point, in that most other projects have one train going
forward (master) and tags identify releases, and release branches can be
used to make releases.  Release branches actually would be inherently
more stable than asking 130 repositories to stop merging to master, as
evidenced by the 1.69.0 release efforts by @Marshall Clow
<mclow.lists_at_[hidden]>.

One way we could think about addressing it is to have all PRs go into
master,
and when we're ready to cut a release, we cut a branch in every repository
with
the same name, i.e. "release/boost-1.70.0".  The release gets done there.
Changes get merged back to master.  All the while, progress on master can
continue.  If you need to cherry-pick something into 1.70.0, you do so into
the
release branch in your repo.  Someone has to update the release branch in
the
super-project too.  My guess is some tooling and automation would need to
change.

I'm okay either way really.  I've learned how to use develop and master
effectively, but if we switched to just having master and used release
branches, that would be more in line with what everyone else does.

- Jim