At 7:19 PM +0200 8/26/08, Christian Larsen wrote:
>Robert Ramey skrev:
>>Christian Larsen wrote:
>[SNIP]
>>>Yes, that's right. But still I don't see how that would make it
>>>possible to keep a stable interface, and make point releases of
>>>that. Unless
>>>all developers agree to only merge non-interface breaking changes into
>>>"ReleaseReady".
>>
>>You're correct that this depends upon developers not merging
>>interface breaking changes into "ReleaseReady"
>>
>>We recently had a discussion about just this topic. I expressed
>>the position that such interface breaking changes should be
>>considered bugs. I also pledged to personally consider
>>such changes in the serialization library as bugs and treat them
>>as such. Much to my amazement, the idea that all boost
>>developers should adhere to such a position was considered
>>by some to be a bad idea. To me it is the bedrock of serious,
>>quality software.
>
>I completely agree, and that's also how I like to think of Boost, as
>serious, quality software. Not having a stable interface gives the
>impression that Boost is "hobby" development only, and can't be used
>for serious purposes. But that's really a shame, as I consider the
>Boost developers as some of the best in the world!

I disagree.

Changing interfaces, to me, implies that the developer:
* Discovered a better way to solve the problem that he faced.
* Decided that the benefits of the change outweighed the costs.

The "don't change interfaces, ever, no matter what" is why we still
have "strcpy" and "mktmp", to name just two examples. Bad interfaces
are bugs; they should be fixed.

Software does not spring full-blown from someone's forehead; it is a
process of discovery and refinement. Interfaces follow that same path.