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