Re: [boost] Re: When will 1.31 be released?

From: Joel de Guzman (joel_at_[hidden])
Date: 2004-01-10 04:53:57

Edward Diener wrote:

> Joel de Guzman wrote:

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

Yes. That's what we are doing now.

Either way, I think it would be reasonable to ask that libraries
#define a VERSION. Outside the sphere of libraries already included
into boost, there are other libraries that use boost and depend on
some of its libraries. Clearly, in this case, these external libraries
have its own release mechanisms asynchronous to boost's. It would make
sense for these libraries to check the dependency and issue an #error
if some requirement is broken.

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net