ReL[boost] Re: 1.32 release preparation

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-06-28 23:31:44

David Abrahams <dave_at_[hidden]> writes:

>> Robert, I'm very happy to have your contributions in this discussion,
>> but it's hard to take your diagnosis of where the problem lies all
>> that seriously when you haven't even been through a single Boost
>> release with a library of your own!

>I hope I didn't squash the discussion with this remark; I'm really
>interested in exploring the possibilities here.  I guess I should've
>asked how you formed your impressions of the problem's cause.

As I recall, the previous release was scheduled for beginning November.  I
was working on the serialization library at the time and using the
development tree at the time.  When the release was announced, lots of new
stuff was added.  There were a couple of tweaks in the new iterators which
required changes for me to keep up.  Trying to develop new stuff based on he
development tree became inconvenient but I needed features not it 1.30 .
Then about the middle of January "is_abstract" was dropped in.  This was an
evolved version of one I had adapted from ?R Sharoni's code.  It was
slightly different from the original in the way compilers not supported.  So
we didn't have real good knowledge about which platforms supported it and
what value it should return on platforms that didn't support it.  I was
considered a very small change but consumed maybe a week of back and forth.
It became clear that I could not submit a proposed serialization library
based on the development tree that could be reviewed by large number of
members downloading the library over an extended period without users
encountering a lot of frustration and my trying to keep up with a morphing
main trunk.  As soon as it was released, I switched to maintain
compatibility with the released 1.31 and it has worked out well.  Based on
this experience, it is my perception that the main development trunk was at
least somewhat fluid over a period of 2 to 3 months and this made
development more difficult.  These are just the things I happen to run into
first hand.  The traffic on the list left me with the impression that my
experience wasn't unique. 

That is how I formed my impression of the problem's cause.

It is my reluctance to contribute to this problem which has discouraged me
from checking in the serialization library until it is at a point where I
believe there are no undocumented bugs/deficiencies.

That is why the serialization library is not yet checked in.

At this point nothing in boost depends on the serialization library.  Should
that change in the future, this discussion convinces me that before checking
in any non-trivial changes, I should re-run the whole test suite on my local
setup.  In the case of MPL, I would think that it would be prudent to run
that part of the test suite that depends upon MPL on one's local environment
before checking it in - given that we don't use a branch for untested code.

Robert Ramey