From: David Abrahams (dave_at_[hidden])
Date: 2004-06-28 06:37:24
"Johannes Brunen" <jbrunen_at_[hidden]> writes:
> On Sun, 27 Jun 2004 19:05:45 -0700, Robert Ramey wrote
>> Here is the current scenario.
>> a) The announcement gets posted - release 1.32 scheduled for date x.
>> b) Each developer decides - uh oh I better get in my changes before date x.
>> c) Of course these changes take longer
>> d) and break some other things
>> e) which takes longer still
> IMHO, point d) touches a weak point: There are two kind of libraries in a system
> like boost. At first, there are core libraries which are used by many other libraries.
> Changes at these libraries are potentially dangerous and must be well-considered
> since they can broke a lot of stuff. They should early checked into CVS to get
> time for stabelizing the base. Secondly, there are libraries which 'only' provide
> a special feature like the boost graph library the circular_buffer library. They shouldn't
> be expected to lead to regressions of other boost libraries. I think that they could be
> handled differently than the core libraries.
Boost.Graph changes have caused plenty of regressions in Boost.Python
in the past.
>> Once a library is accepted, then one can get serious about making it pass
>> with a larger number of compilers. This also takes time - a lot of
> Passing compilers which weren't supported during the review process under no
> circumstances shouldn't delay the integration of the library into the boost
> main pool.
> Supporting a special compiler is only a nice to have feature.
> This means not that it not worth spending the effort supporting important
> platforms. However, in the first iteration I just expect a library to be
> written in ANSI C++ and to be usable on platforms which support it.
I absolutely agree with that. No library needs to support vc6 in
order to be acceptable. Get it checked in, then improve its
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com