"Johannes Brunen" <jbrunen@datasolid.de> 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. <snip>
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 time
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 portability incrementally. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com