Re: [boost] Development and Release Practices

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-08-08 00:46:24

Joe Gottman wrote:
> changes to the other classes that would not break
> most
> clients will break the serialization code: for example if a class
> adds a
> new data member and a constructor with an extra parameter to
> initialize
> it.

This is not a problem.

The serialization library will no have any new serialization 
implementations.
In the future, all serialization implementations have been part of
the library which defines the type.  It has been this way in
the begining for data-time, multi-indexe, ranges? and I'm sure a
number of others.  So it would seem that I'm only stuck with
the stl and a couple of others like shared_ptr and variant.

But its not even that bad. STL isn't expected to change, and
Matthias Troyer has continued necessary refinements for
collections so that leaves just a couple to keep me honest.

Its true that serialization uses a lot of boost for its implementation.
This is a "good thing (tm)" as the serialization library is larger
than I'd like anyway.  But if someone breaks a published interface
that I use, well, I'd get upset and we'll have to sort it out
the old fashioned way.

But this brings up a couple of very interesting examples.

a) spirit - No way did I want to deal with parsing XML.  A big pain
to do and worse to maintain.  Spirit save my life here.  But it is
much more than that.  Joel has kept faith in leaving the original
library around so that serialization still works with older platforms
like borland 5.51 and msvc 6.0 and who knows what else.  I haven't
had to tweak the xml parsing for a couple of years (except to fix
one or the other mistake in grammer specification.  I can't emphasise
how important this is.  It means I can hand off a significant part of
the implemenation the library to another library and forget it and move
on.  Contrary to what it might appear - serialization is not my life
and thought I like to keep my hand in from time to time, I don't want
to have to constantly go back and add stuff in that someone doesn't
support anymore.  Making something that people are really going
to depend on in a real product requires this professionalism and
commitment that frankly most people don't really appreciates.  So,
Joel, if you ever think of getting a real job, feel free to ask me
for a letter of recommendation.

b) The other example is the boost test library.  I read the documentation
and I thought it was wonderful.  I had seen unit testing promoted
before but really it was just lip service. Following the instructions
in the manual and examples let me write 50 tests for the serialization
library.  My needs were well served by the header only version
and I was satisfied.

But, then the test system started to break with older compilers.
This was due to enhancements in the library that older compilers
couldn't support. I complained, but the response I got was that
I wasn't spending my time well supporting the older compilers
so basically, I was given the choice of elminating dependence
on Boost Test or throwing away serialization library support
for older compilers.  I confess I resented having to make
such a choice - but I had no choice but to choose.

And in a nutshell, this is what will happen and what must
happen when a library's published interface changes. It's
happened in the past and will happen in the future.
Its not really a function of the test/release policies - its
just is.

Improved test/lrelease policies can detect this in a timely
and orderly manner - but the resolution willl be as
it always has been.

Robert Ramey