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

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-05-04 11:22:39

Nicola Musatti wrote:
> Robert Ramey <ramey <at> rrsd.com> writes:

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

Why? one would have on his machine either

a) last boost release version
b) or last boost release version + validated upgrades.

I don't see how this would make anything harder.  If for some reason
it does, you can always just skip the upgrade and wait for the next boost 
release.
That is, one can be no worse off than he is now.

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

It seems that this is functionally equivalent to my proposal.
>
(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]).

Well, the current situation is a hodgepodge as it will always be.  I've
supplied serialization support for standard collections and Matthias
Troyer has enhanced it.  I've done it for a couple of  types which
I tought were important but it seemed it wasn't getting done any
other way (e.g. shared_ptr) and some which were contributed
(e.g. variant) and some have been done by the respective authors
(e.g. data/time, multi-index).  Right now they are in the namespace
of the author - seems kind of arbitrary to me.  And some authors
have included serialization headers as part of "convenience headers"
which I'm not crazy about.  On the upside, though this "hodgepodge"
lacks a certain aesthetic consistency, it doesn't create many
real problems and trying to get everyone on the same page would
be so hard as to not be worth the trouble.

> 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.
>
> This will help shorten the Core release cycle, while allowing large
> libraries developers to proceed at their own pace.
>
> Users will also benefit from not having to download/install/build
> libraries they do not need.

So, you're agreeing with me? or not?

Robert Ramey

> Cheers,
> Nicola Musatti
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost