Boost logo

Boost :

Subject: Re: [boost] [git] Update submodules in boost.git
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-12-05 02:43:40

On Thu, Dec 5, 2013 at 11:07 AM, Daniel Pfeifer <daniel_at_[hidden]> wrote:
> 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]>:
>>>> Hi,
>>>> 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 thought of it as of one of the possible models. So far boostorg only
required develop and master branches as the replacement for trunk and
release of svn.

Personally, I plan to keep my work flow close to the one I had with
svn, i.e. I commit to develop, and when it passes tests I merge it to
master. I don't plan to form releases of these merges.

>> 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.

So this basically means that each library has to have its own testing
farm, and Boost serves mostly the bundling purpose. A possible
solution, I guess, but not sure such approach would be beneficial for
the quality of Boost. I doubt that individual developers will be able
to do the same amount of testing for their library releases as they
had with svn.

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