From: David Abrahams (dave_at_[hidden])
Date: 2004-06-29 10:19:20
"Robert Ramey" <ramey_at_[hidden]> writes:
> 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.
Right; last-minute major changes in Boost.Test and shoving in
"is_abstract" caused big problems.
> There were a couple of tweaks in the new iterators which required
> changes for me to keep up.
That doesn't mean there was "experimental" code in the tree. I
fixed everything I could find in CVS that depended on the change.
If serialization had been in the CVS you'd have had no trouble with
> 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.
That was just a mistake; It's not supposed to happen that way. It was
decried by many of us and the person who did it is now contrite.
> 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.
I doubt you'd notice any difficulty with the current CVS state
either, but I could be wrong.
> 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
Well, yeah! It has to change sometime, doesn't it?
> 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.
Thanks. I think a lot of people had the same problems you did with
is_abstract, so it wasn't unique. It was, however, unusual. We don't
normally operate that way -- although it was at least the 2nd release
in a row where last-minute changes to Boost.Test caused major
> 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
> That is why the serialization library is not yet checked in.
I think that's sensible, unless the kind of deficiency you're
referring to is "compiler X has a bug and the library doesn't contain
> 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.
Of course. If anyone's not operating that way, maybe we need to make
it an explicit guideline.
> 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
Once again, of course. That's exactly what Aleksey said he would do.
> - given that we don't use a branch for untested code.
But we do; the upcoming MPL code is on a branch. (?)
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk