Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-06-04 14:01:33

Gennadiy Rozental wrote:
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> news:012301c7a6cc$59a39360$6407a80a_at_pdimov2...

>> My current development model is sync against CVS HEAD, do work,
>> commit, check test results, fix. My use model is sync against CVS
>> HEAD, compile project, yell at whoever introduced a regression in
>> the boost component I'm
>> using. This works well for me and I'd like to keep working in a
>> similar way.
> IMO this is not the desirable scheme in general. Actually this is
> exactly what we *should not* be doing IMO.

It works for me.

As a Boost user, I simply don't use Boost components whose HEAD versions are

As a Boost developer, if a dependency takes too much time to stabilize, I
sever ties with it and reimplement the parts I need. This is rare since I
have low tolerance for dependencies anyway. :-)

I understand that this mindset may be unusual. Still, I find the idea that
the trunk is assumed to be unstable a bit odd. The trunk should be stable
and everyone should work to keep it that way.

> What directory structure are you talking about?




the key point being that a library is not allowed to put anything else in

>> The dependency management can also be introduced at a later date. It
>> is not
>> as fine grained as in your proposal - you can't depend on a specific
>> version - and this is intentional, to keep things simple.
> What value does it have then? This is what we got now "informally".

The value of the dependency management is to allow subsets of Boost to be
tested and released.

>> This step requires
>> the test infrastructure to be updated to allow testing a specific
>> library and only pull a subtree.
> If there is no way to point to older version of my depenencies, what
> the poiont of subtree pulling? They all going to be the same.

The point of subtree pulling is to verify that the library can be built
against its dependencies, not against the full boost/ tree as we currently

>> A release also doesn't require any new tools; it can be done
>> manually by the
>> release manager. We may be able to streamline it with tools in the
>> future, of course.
> Release still require all libraries to be tested together, right?

Right. The release process basically consists of integration testing.

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