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 <darylew-AT-hotmail.com> wrote:
> * I see we have a GitHub account at https://github.com/boostorg, 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 github.com/boostorg/, 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
https://github.com/boostorg/boost, 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 http://github.com/boostorg/boost 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk