Re: [boost] Boost Development Environment proposal

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

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?

boost/

  foo/
  foo.hpp

  bar/
  bar.hpp

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

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

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