Marshall Clow skrev:
At 10:38 PM +0200 8/26/08, Christian Larsen wrote:
No, no, please don't get me wrong. I'm not against changing interfaces in general, of course that's by all means the way to go if a better way is discovered. What I was trying to say is just, that for some uses it is nice to have a stable interface to stick to for a period until you decide yourself that have the time to upgrade to a new, and improved interface. Thus proving both options would be optimal, from a user's point of view.
But that way lies madness :-( Basically, you can never remove an interface, because someone, somewhere might be using it.
Never to remove interfaces is not what I'm trying to advocate either. ;) Just to provide bugfixes for a stable interface for some period (like the major release cycle), so that people can adjust over time, and decide themselves exactly when in that period they have the resources to do a full upgrade. Once the next major release is out, you are free to "rm -rf" the old release branch, I couldn't care less. We all know that no software is perfect, although some gets close, so it may be too long to wait for next major release to get bugfixes. What you say is that for instance, if a nasty bug was discovered in shared_ptr (which is highly unlikely, I know) some time after a release, people should just immediately jump to the newest "ReleaseReady" no matter what other (possibly interface breaking) changes have been made to Boost as a whole. Then they'd have to port all their existing code to conform to all changed interfaces at that point in time, because the developers decided that the time was right? And that is just to get a single bugfix. It could require a whole lot of work, reading changelogs, and documentation etc.
Of course developers should improve interfaces all the time, but it is impossible for them to "decide" whether the benefits of the change outweigh the cost, because for some users the cost might be high.
I disagree (again). The authors of the libraries are the only people who can decide when to change the interface.
Of course they decide when to change the interface, but they can never decide when that change can be followed up on by users of the libraries. Not all users are able to throw away whatever they are currently doing, to sit and update their codebase to new interfaces, whenever they would like to have a bugfix. Which is why I think interface breaking changes should be insulated from a release branch in the first place... [SNIP]
Thus, from a user's point of view, the optimal approach is having both versions to choose from: a "bleeding edge" version including all improvements, and a "stable" version that you can use for a while until you decide yourself to upgrade to the new interfaces.
Oh, is that what you're looking for? Boost already has that! The "stable versions" even have names: 1.34, 1.35, 1.36 (etc). As long as you use 1.34 (for example), the interfaces are guaranteed not to change. :-D
Yes of course, but also from following the list, there has already been discovered bugs in the newest release, which is why people are discussing whether to provide hotfixes. ;) As I see it there currently is no way of ensuring that users can benefit from bugfixes while still relying on a stable interface. It's either all or nothing. Best regards, Christian