Boost logo

Boost :

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

> 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
> bugs/deficiencies.
> 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
a workaround".

> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at