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

From: David Abrahams (dave_at_[hidden])
Date: 2008-07-16 15:38:26

on Wed Jul 16 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:

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

Sorry.  It sounded, when you said the semantics wouldn't be changed
without notice, that you meant you might change them "with notice."
Personally, that's what I would do/support, with a stricter definition
of "with notice" of course.

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

Sometimes that's impractical, but it's great when it works.

> 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 think a blanket statement like that about all Boost libraries is a
good idea.  Even some of our oldest and most stable libraries change
their semantics in small or large ways occasionally.  SmartPtr comes to
mind.  One reason to make such changes is that a *slightly* different
version of the library is now in the C++ standard or WP or a TR.

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

I'm very pleased to hear you say that.

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

Maybe -- but not with me, on that point.

> so no need for anyone to point this out.  I just like to have my say.

Don't we all ;-)

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com