[boost] Re: When will 1.31 be released?

From: Edward Diener (eddielee_at_[hidden])
Date: 2004-01-09 21:42:18

Joel de Guzman wrote:
> Beman Dawes wrote:
>
>> At 11:50 AM 1/8/2004, Robert Ramey wrote:
>>
>>  >When will 1.31 be released?
>>
>> When we get tired of tweaking it.
>>
>> John Maddock (the brains) and I (the testing brawn) just finished
>> Intel and Metrowerks auto link support. Whew! Hours and hours of
>> testing.
>>
>> Win32/gcc is broken. That needs to be fixed.
>>
>> But I'm about worn out, and would like to put together a release
>> candidate.
>>
>> What is the status of the iterator adaptor docs? Are they stable yet?
>
> I'm also still working on finishing the Spirit docs. It's mostly ok
> now. But I wish to spend a few more hours on it after I get over this
> flu.
>
> I think we should start to discuss the possibility of having
> individual releases (as Spirit is doing right now) instead of one
> monolithic release. I'm sure you are all starting to feel the weight.
> At some point, when boost assimilates more libraries, a monolithic
> release might take forever. This seems to go against the open source
> mantra "release early, release often". There will be issues, of
> course. Spirit is experiencing some of them now. For instance, which
> version of Spirit works with which version of Boost
> is a common question. Thoughts?

If you decide to do this, I think you need to build some sort of version
dependency situation into Boost. This would mean that an individual library
which depends on some other library would be checking via header file
defines that the other library was of a particular release or earlier. If
not, a preprocessor #error would prevent the individual library from working
with the updated library. If a particular library gets updated outside of
Boost, then any other libraries which have a dependency on that library
needs to also be updated as least as far as the header files defines are
concerned and also redistributed, lest the changes make to the original
library break code in the other libraries which use it.

While this is a PITA it needs to be done so that libraries being updated on
their own release cycle don't break other libraries already released on the
main Boost release which depend on the changed library for some of their
implementation. Any other situation seems fraught with danger and confusion.
Whether all this extra mechanism is worth putting out individual releases of
libraries away from the main releases is something for Boost implementers to
consider. But if such a system is created, please consider the above and its
effect on the lowly end-user if some sort of schema as outlined above is not
implemented.