Boost logo

Boost :

Subject: Re: [boost] [git] Some questions on Git transition
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-08-24 16:01:36

on Wed Aug 21 2013, Daryle Walker <> wrote:

> * I see we have a GitHub account at, with
> repositories for each library.

Yes, those repositories are being generated dynamically from SVN by

> If we add a new library, and it has been Git-based, are we going to
> mirror it in the Boost account?

Well, we'll have a repo for it under, which will be
where the official Boost releases are made from.

> That'll make sure if something happens to the original, we still have
> a last-known-good to work with. Would having all the libraries (or
> copies/mirrors) under the same account make scripts easier?

Yes, and we plan to do that.

> What about non-Git libraries, will they be copied over?

What's a non-Git library? Serious question.

> Would a bridge be used? (There's at least bridges for Git connecting
> to either Subversion or Mercurial.)

Boost libraries will be officially developed under Git. People can use
bridges or other tools to develop if they like, but Git is going to be a
requirement for Boost libraries going forward.

> * We currently ship all the libraries merged together as a single
> archive. Some package managers even provide the Boost libraries as a
> single item. When we go Git, is that still going to be in place (with
> the release managers doing some sort of merging script), or are we and
> every user going to move to doing several dozen downloads instead?
> (And everyone has to figure out how to use more than one Boost library
> at once.)

There are two answers to this, no and no. :-)

The first "no" is that we are also producing, which is a monolithic snapshot of
everything that refers to the other repositories as submodules. All of
Boost's SVN history is captured there, and after the transition each
whole-Boost release and release candidate will be available in that
repository as a tag.

The second "no" is that Ryppl is intended to be a tool that manages
inter-library dependencies and resolves them for you as needed, so that
you don't have to grab all of Boost just to do a bit of development.
But Ryppl is a long-term goal, not a short-term reality.

> * Are we eventually going to use something like

We have already agreed to use exactly that model (git-flow).

> If so, are we going to use that to script releases? (At release-time,
> grab the latest version of each library from their master branches,
> apply the merging script, run tests, then ship.)

What merging script? :-)

The plan for monolithic Boost releases is to continuously test a
revision of whose submodule references
point only to release tags in each sub-repository. When the release
managers like those test results, they can ship the release.

Dave Abrahams

Boost list run by bdawes at, gregod at, cpdaniel at, john at