Re: [boost] [1.36.0] Libraries with unmerged changes?

From: Robert Ramey (ramey_at_[hidden])
Date: 2008-07-16 16:04:48

David Abrahams wrote:
> on Tue Jul 15 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
>
>> I, Robert Ramey, hereby declare:
>>
>> a) the serialization library to be "frozen".
>> b) the documented interface and symantics will only be extended - not
>> changed
>> without notice.
>> c) should any program which depends upon the published interface and
>> semantics
>> fail to work or stop working - I will acknowledge that this is a BUG
>> and endeavor to fix it.
>> d) Going further (specific to the serialization library) - the
>> intent of the serialization library
>>  is that newer version be able to load files saved by all previous
>> versions. Any case where this fails will be acknowledged as a BUG.
>>
>> I would ask that library authors that cannot make a similar pledge
>> include a disclaimer in thier documentation and header files
>> something on the order of:
>>
>> "I (the author) expect to make future changes in this library.
>> These changes may have the effect that in the future you're program
>> will fail to compile, link, and/or execute as expected.  Since I
>> don't
>> know who might use this library, it is impractical for me to
>> notify you - Sorry about that - Good Luck."
>>
>> That would permit me as a user to take appropriate precautions.
>
> I'm sure everyone would make the same pledge as you, as long as it has
> the same back door clause allowing semantic changes "with notice." ;-)
>
> At least that's how I read your pledge.  If you mean something else
> you should try to clarify it.

Personally I don't mean "with notice".  I mean exactly what I said.

Personally,  I'm really relucant
make these kinds of changes.  However, I do recognise that in
spite of the best of intentions they do occur.  To me a canonical
example is auto_ptr.  Over time it has come to be seen that
there are some problems with the interface/semantics.  Those
in charge (whoever they are), I believe have chosen to make
differently named entity to address the situation.  To me, this
is this a good example of how these situations should be handled.

Also to be fair, the serialization library has been around a while
and we didn't find any agregious errors of this kind.  (This
is likely due in large part to the boost reviewing process).  So
its much easier for me to make un-qualified pledge as the above
than it would be for a brand new library.

Actually, the disclaimer is a lot more interesting.  Suppose
that boost asked for (a less provacatively worded) disclaimer
for authors who want to be able to do this.  Something like:

".... library is a new library.  As it becomes more widely used,
and we get more feed back from real users.
We expect that we may want to make some modifications
to some of the interface and/or sematics of the library.  We
will endeavor to avoid this, but sh*t happens. So
please be aware of this and double check the documentation
and release notes when moving to a more recent version
of this library.  Perhaps in the future, we will be able to
guarentee that the interface/semantics of the library will
not change."

more or less.

I don't want to get tooooooo serious about this.  But I think
really do believe that modern software engineering is too much
like "traditional engineering" where we build and test.  I would
like to see it more like "mathematics" where things are proved
infallible by construction.  This difference crops up unexpectedly
from time to time - e.g. what is the mean of a failure in "assert"
and how should it be dealt with.   Of course we're
off topic, and of course I'm way out of sync with the rest of
the world, so no need for anyone to point this out.  I just
like to have my say.

Robert Ramey