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