Re: [boost] master and develop branches

Subject: Re: [boost] master and develop branches
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2017-09-07 19:41:47

On 09/07/17 22:07, James E. King, III via Boost wrote:
> Could someone point me to documentation on management of the master and
> develop branches for committers?

I'm not sure if there is any document for git; I've only found the 
outdated version from the svn days:

https://svn.boost.org/trac10/wiki/DeveloperChecklist

It mostly applies if you replace trunk -> develop and branches/release 
-> master.

So your development typically happens in your branches or develop (for 
smaller changes). The develop branch gets tested, you can see the 
results here:

http://www.boost.org/development/tests/develop/developer/summary.html

When your changes are thoroughly tested in develop (i.e. the tests 
detected no regressions) you can then merge them to master. Master is 
also regularly tested:

http://www.boost.org/development/tests/master/developer/summary.html

Note that if your changes depend on changes in other libraries, you 
should generally check that those changes were merged to master before 
merging yours. If they are not merged for a long time you can ask the 
maintainers to merge them (usually through a PR on GitHub).

Boost releases are made from the master branches of all projects. The 
master branch is frozen during the preparation of a release, which is 
usually announced on the ML. You should avoid merging develop to master 
during the freeze.

>  boostorg/uuid master ends at Jan 11.
>   boostorg/develop has a bunch of stuff in it starting on August 3, 2017.
> Who is responsible for merging develop into master and when should that
> happen?

The library maintainer is responsible for the merges.

>  Some of the issues are already marked resolved with a milestone of
> 1.66.0 but they are not in master, only develop.

If they have passed testing, they can probably be merged to master.

> Should pull requests on github go directly into master?

No, all pull requests (PRs) should only go to develop. As do all your 
own changes. Only after being tested in develop they can go into master.

>  I find it
> confusing to have both and would prefer if there was only one possible
> destination for pull requests on github.  If there are two, someone has to
> keep one of them updated and that isn't very efficient.

The reason for having develop as the bleeding edge is to keep master as 
stable as possible and always ready to release. It is nearly impossible 
to release more than a hundred libraries in a Boost release if active 
development happens on master. Therefore always merge PRs to develop, 
never into master. Only merge develop into master, after testing is done.