[boost] Re: ReLRe: 1.32 release preparation

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