Re: [boost] Breaking existing libraries

Subject: Re: [boost] Breaking existing libraries
From: Markus Werle (numerical.simulation_at_[hidden])
Date: 2008-12-02 18:25:26

David Abrahams wrote:

> Of course backward compatibility is desirable, 
> but maintaining it rigidly prevents forward progress.  

This is one side of the medal.
Don't call it backward compatibility but maturity
and stability. The aim of the critique probably is
clear distinction in maturity and stability for
different parts of boost.

Example:
In case of spirit we have the following situation:
spirit2x (nomen est omen) is a *completely* 
different library with a completely different 
interface written on a different base and a really 
inferior stability compared to spirit 1 
(Even though it is ultimate high quality code and 
I begin to like it).
Now that I became aware of what it means for me that
good old spirit gets dropped and reworked this way 
I wish its new name was boost::ghost or whatever and 
spirit left in the state of 1.34.1:
It works, it is fine, it has - of course - some limitations.
So what? The parsers I have written with spirit are
those parts of my code I never had to touch again 
(except once, see below).
Sometimes no change is good.
Also because I know most of spirit-1 oddities by heart
and can fiddle small parsers within minutes I do not want 
to switch to 2x now.
I acknowledge the hard work done to keep spirit1 in
the distro, but I still dislike the way it was solved,
because I'd prefer spirit-1 to be a first class citizen
for at least 3 more years.

> Judicious breakage does not necessarily mean that 
> the library is "experimental" in any meaningful way.  

Yes and no.
If you touch it you probably will break one thing or 
another (and agile as you are fix it in 5 minutes after 
bug report).

IMHO this also is a communication issue.
On this list several people (me included) have already 
proposed to introduce stability labels. 
E.g. spirit2x *should* be tagged highly experimental
pre-alpha code *despite* Joel's programming skills until 
many many users confirm its correct behaviour in Real World code.

We have to separate the quality label of the library 
from the quality label of its authors. Maybe that helps.

> Nobody really has a problem with the stability of shared_ptr, for 
> example, and yet look at its list of breaking changes over the years:
> 
>   http://www.boost.org/doc/libs/1_37_0/libs/smart_ptr/compatibility.htm

Most of these were extensions, bugfixes or improvements, 
not interface or silent breakage, right?

The counter example:
I had hard times with the rather silent change in spirit concerning 
trailing whitespaces and enforcing end_p.
(http://www.nabble.com/Re%3A-grammar-rules-problem-p15635719.html)
I agree with the change decision, but the change could have been 
advertized in big red letters on the main web page.
It took me several months to detect _and_ understand the rather 
subtle errors it generated and this prevented migration to a new version 
of boost for a long time. 

This is OK for me, since Joel saved me a lot of time, but yes,
this *change* broke all my code at once - silently. Something
I do not like at all. 

The question is: can we work around this kind of problem easily?
I guess, no. 

In another post you ask:

> So what happens to the iterators library when it's time 
> for the rewrite I've been planning?  I intend, as much as 
> possible, to maintain compatibility with the old interfaces, 
> of course.  Is that still a "stable" library?

Considering the interface: no. 
I'd prefer you advertise and introduce a new library as 
replacement candidate for the old library and have 
them both, the old and the new one, live together in boost 
for at least one year before the switch and the deprecation 
of the old one takes place. By this you have 2 things at a time:
Fast release process *and* satisfied customers.

Markus

P.S.: I am on my knees again: I managed to *use* iterator_adaptors 
without understanding them at all. It works and I never had to 
touch the code again for 3 years now. Thank You.
I now forgot everything I once read and learned about iterators. 
Please don't change it ... please ... 
:-)