Re: [boost] [BoostCon07][testing] Session reminder.

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-05-04 12:21:52

"Nicola Musatti" <Nicola.Musatti_at_[hidden]> wrote in message 
news:loom.20070504T111058-122_at_post.gmane.org...
> Robert Ramey <ramey <at> rrsd.com> writes:
>> Gennadiy Rozental wrote:
> [...]
>> > I pitched them while ago once. And I still believe that the
>> > synchronization is the root of all evils. The only real solution to
>> > break this deadloop is independent libraries versioning. This should
>> > resolve both out release and testing issues (which are closely
>> > connected IMO)
>>
>> This is on the right track - but seems way too complicated.
>>
>> Here is what I plan to do from now on:
> [something along the lines of: develop locally against the latest Boost 
> Official
> release]
>
>> e) When it passes all my tests on the compilers I have.  I will do the
>> following:
>>     i) check in my changes into whatever tree boost decides it wants to
>>    ii) zip up the files which are different from the last boost release 
>> and
>>    upload the ziped file to a place on my website.  The website will
>>    contain instructions on how to set up one's include paths so that
>>    the latest validated serialization library can be used.
>
> This is going to make it incredibly hard to use  in the same project both
> serialization and any of the libraries that changed since you set up your
> environment.

I agree.

> I believe there are two problems in Gennadiy's proposal: the granularity 
> is too
> fine

It's natural separation by independent libraries

> and the constraint of releasing Boost in a single whole is going to make
> things unnecessarily hard.

Which constrain?

> A better approach would be to separate from core Boost some of the larger
> libraries once and for all. I'm thinking of Serialization, Spirit, Python,
> possibly a few others. In most cases other libraries should not depend on 
> these
> (i.e. Preprocessor is not a good candidate). Where dependencies exist they
> should either be removed or moved to reside within the separate library 
> (e.g.
> serialization support for core libraries should be supplied by 
> serialization and
> not core [as I believe it is now, at least in many cases]).
>
> These libraries should be developed, tested and released separately, 
> against the
> most recent release of core. It will be up to each library mantainers' 
> team to
> decide whether to "port" one or more released versions of their library to 
> new
> releases of Boost Core, while they work on a new major release.

1. This in no way address problem developing and releasing libraries that 
other depend on. And this is biggest problem IMO
2. You proposition leads to the separated librarties to be potencially 
unusable with latest boost release. This is not a good thing IMO.
3. Who make this decision? Which libraries are "core" and which are 
standalone?

Gennadiy