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

From: Nicola Musatti (Nicola.Musatti_at_[hidden])
Date: 2007-05-04 13:44:01

Gennadiy Rozental wrote:
[...]
>> I believe there are two problems in Gennadiy's proposal: the granularity 
>> is too fine
> 
> It's natural separation by independent libraries

I might agree if they really were independent, but in many cases they 
are not. On the other hand there are a number of rather large libraries 
that have fewer dependent ones.

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

I'm under the impression that in your scheme you expect to be able to 
assemble a complete Boost release by choosing the appropriate releases 
of all the component libraries.

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

All that is needed is to shift the release date of the split libraries 
some 2-3 months after the release of core, assuming a six month release 
cycle. Core developers will take advantage of the more manageable size 
of the library collection they work on, while split libraries' 
developers will gain from the resulting period of Core's guaranteed 
stability.

> 2. You proposition leads to the separated librarties to be potencially 
> unusable with latest boost release. This is not a good thing IMO.

People that only use core will be able to switch to a new release 
immediately; those who need one or more of the separated libraries will 
have two wait up to three months. On the other hand by reducing Core 
Boost to a much more manageable size than whole Boost is nice, the 
chances of hitting planned release dates should increase. If you 
consider how long people have been waiting for the libraries that were 
introduced/improved in 1.34, not to mention those that are expected for 
1.35...

> 3. Who make this decision? Which libraries are "core" and which are 
> standalone?

This will have to be agreed upon, considering size, dependencies and 
breadth of applicability. Ideally library authors should offer to split 
off their libraries if they think it reasonable. In a way Robert Ramey 
is already heading in a similar direction with Serialization. I think he 
should be encouraged to do so, but within an agreed upon setup, rather 
than in total independence, so that other authors may benefit from the 
experience gained.

Cheers,
Nicola Musatti