Re: [boost] Should we provide hot fixes?

From: Christian Larsen (contact_at_[hidden])
Date: 2008-08-26 17:30:32

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