Re: [boost] Getting Started with Modular Boost Library Maintenance

Subject: Re: [boost] Getting Started with Modular Boost Library Maintenance
From: Cox, Michael (mhcox_at_[hidden])
Date: 2013-12-25 14:52:02

After reading the thread "avoiding fast-forward merges" and looking at the
latest https://svn.boost.org/trac/boost/wiki/StartModMaint, I'm getting
totally confused on the boost git flow.  I thought  all the commits on the
develop branch of all the repositories are fast forwarded onto their master
branches.  Note, that the --no-ff still tries to fast forward the branch
and adds a merge commit if  the fast forward succeeded to "mark" the merge
into master (not sure this is really necessary, since you should have a tag
on that last fast forwarded commit The develop branch should *always*
fast-forward,
unless some history editing has occurred.  Here's the description of the
fast forward options from the man page of git-merge.

        --ff
           When the merge resolves as a fast-forward, only update the branch
           pointer, without creating a merge commit. This is the default
           behavior.

       --no-ff
           Create a merge commit even when the merge resolves as a
           fast-forward. This is the default behaviour when merging an
           annotated (and possibly signed) tag.

       --ff-only
           Refuse to merge and exit with a non-zero status unless the
current
           HEAD is already up-to-date or the merge can be resolved as a
           fast-forward.

In fact, since we can't enforce fast forward merges on the server side on
Github, The command line option should be --ff-only. That way if the merge
fails, you know somehow a commit got on master that isn't on develop or
maybe you have some stale branches you need to re-pull.  With the --no-ff
option and a master that isn't in sync with develop, you'll just put a
merge commit on master and not fast forward the development history from
the develop branch onto master.  If you're lucky, you might get some merge
conflicts that will alert you to the problem.

On the StartModMaint page, there is command line sequence:

cd modular-boost
git checkout master
git pull
git submodule update

Shouldn't that be "git checkout develop"?  Are we not using the develop
branch at all?

Michael

P.S.  I tried to merge the develop branch onto the master branch in my
superproject of my local repositories to simulate a release of boost.  I
got a ton of conflicts (looks like mostly submodule reference commits).

Michael

On Tue, Dec 10, 2013 at 9:41 AM, Beman Dawes <bdawes_at_[hidden]> wrote:

> I've been pecking away at "Getting Started with Modular Boost Library
> Maintenance".
>
> See https://svn.boost.org/trac/boost/wiki/StartModMaint
>
> I'd appreciate comments and corrections.
>
> One of the questions that came up was how to number releases for individual
> libraries.
>
> Say Boost.System wants to do a release before the next full Boost release
> ships. What do I call it? How do I document it? How do I tag it?
>
> Strawman proposal
> ------------------------
>
> * Call it "Boost.System 1.55.1 Point Release".
>
> * Document it via the "readme" file that GitHub pesters you to add.
> Contents would give the title of the release and the release notes.
>
> * Create a gh-pages branch with the same release notice.
>
> * Tag it 1.55.1
>
> Comments?
>
> --Beman
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>