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:
It mostly applies if you replace trunk -> develop and branches/release
So your development typically happens in your branches or develop (for
smaller changes). The develop branch gets tested, you can see the
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:
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
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.