[bt-devel] Compatibility break: Sword 1.6RC1->RC2 API change

[Manfred Bergmann]

Am 24.04.2009 um 07:31 schrieb Eeli Kaikkonen:

> Quoting "Troy A. Griffitts" <scribe at crosswire.org>:
>
>> Thanks for the support and I understand the criticisms.  Let me just
>> say that the one difference here is that we are talking about a 1.6.x
>> BRANCH in which NO API changes can be made once it happens.  It is  
>> this
>> point that is weighing heavier on the decision to make the change  
>> right
>> now before the branch.  Honestly, I'd rather have the interface  
>> where I
>> want it right now over stability (obviously I'd like both).  Once  
>> 1.6.x
>> is branched, I have no problems releasing monthly if we feel the  
>> need,
>> but it will likely be another year before we branch again and get
>> interface changes out in the wild.  Hope this helps explain the
>> decision.
>
> It is understandable. We also have to remember that the situation  
> here is quite rare and Troy (or others) didn't have much experience  
> on releasing such an important milestone as 1.6 is. We have to learn  
> from this and not repeat some mistakes.
>
> A library is much more critical than an application. We can release  
> apps just like that, changing whatever, and it may temporarily  
> affect few users. But if there are 5 frontends using a library, a  
> change may affect 5*n developers and 5*m end users. If the app  
> architecture is rigid, one small API change may ruin the whole thing.
>
> It is usual practice to mark some API features deprecated. It could  
> have been done here, too. Better yet, why not let the setter  
> function be (at the moment, put it back). It was there only for a  
> short moment, but in this situation it allowed frontend developers  
> continue with old architecture. If it's important to make sure that  
> the developers understand what they are doing, why not rename the  
> setter as  
> "iSwearToMyHeadThatIHaveShownAWarningToUserAndUnderstandThatPeoplesLifesMayDependOnIt 
> (bool)"
> It still changes the API but doesn't force to subclass. The virtual  
> method and this setter can live peacefully together: the default  
> implementation of the checker would return either the value set by  
> this setter or false.

Yeah. I vote for putting the setter back.
If someone doesn't want to show a requester he can still get around it  
it probably is harder with the virtual method.
On the other hand if someone takes it serious he shows the requester.  
(Btw: MacSword does, too, since a couple of months when this setter  
was intruduced.)


Manfred