Subject: Re: [boost] [git] Update submodules in boost.git
From: Daniel Pfeifer (daniel_at_[hidden])
Date: 2013-12-05 02:07:06
2013/12/5 Andrey Semashev <andrey.semashev_at_[hidden]>:
> On Thu, Dec 5, 2013 at 9:37 AM, Daniel Pfeifer <daniel_at_[hidden]> wrote:
>> 2013/12/5 Daniel James <daniel_at_[hidden]>:
>>> I've just updated all the submodules in the main git repo. I'll try
>>> and do this daily for a little while, but we'll need to automate it.
>>> Preferably triggered by a hook so it's as close to instantaneous as
>>> possible. Any takers?
>> The purpose of modularisation was to allow a modular release process.
>> I suggest the following:
>> Each Boost library has its own release schedule.
>> When there is a new release of Boost library X, you point the
>> submodule in Boost/develop to X/master.
> What if a library does not have any releases? I.e. when there is a
> rolling release which is always HEAD of master? I think many libraries
> are developed this way, or at least this was the case with svn.
There was an agreement that the gitflow branching model shall be used.
> I really don't like the idea that I have to do something to bring my
> changes into the Boost superproject. It's yet another action that I
> have to remember doing some day, and practice shows that merging from
> trunk to release is already prone to forgetting.
>> Tests are run on Boost/develop.
>> To make a new release of Boost, you merge the changes of Boost/develop
>> to Boost/master.
> Does that mean that X/develop is not tested?
Yes (and no). It is not integrated into Boost and it is not tested as
part of Boost. The same way as the development of zlib is not tested
by Debian. Just the releases are integrated and tested.
> Why is it needed then?
According to gitflow, this is where the development of X happens. It
is also tested of course. On its own, however.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk