"Robert Ramey" <ramey@rrsd.com> 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 frustration.

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 http://www.boost-consulting.com