[dev] Horde 5 was: Re: [commits] Horde branch develop updated. fa956a4d83a7227e2a5d47bfe87185854e151fbc

[Michael M Slusarz]

Not to beat a dead horse, but these issues are critical to  
resolve/discuss for the next version so limited reply is below:

Quoting Michael J Rubinsky <mrubinsk at horde.org>:

>>> Imagine this scenario: MIME encoding of an address.  Let's say an  
>>> application parsed the results of an encode for the  
>>> quoted-printable signature to determine if the message was  
>>> encoded, and performed an action based on the encoding status.  In  
>>> a future version of the MIME library, it was decided to change  
>>> quoted-printable encoding into binary encoding.
>>>
>>> This change would "break" the existing application if the library  
>>> is updated but not the Application.  But this is not a BC break.   
>>> This is an example of an application making incorrect assumptions  
>>> about the API.  Nobody could possibly argue that we would have to  
>>> maintain the old way of MIME encoding just because a downstream  
>>> application won't be able to handle it properly.
>
> I guess we will have to agree to disagree. If the MIME encoding is  
> done in a stand alone library, and the behaviour of that library  
> changes in such a way that any existing code written against it is  
> broken due to the change, that is a BC break and warrants a bump of  
> the library's major version number.

You are not understanding the example.  The example I gave displays  
that when an application author ASSUMES something about a library that  
is not a part of the API, a future change in that library cannot be a  
BC break.  In other words, an application itself cannot cause a BC  
break upstream.

The above example would not warrant a major version change in the MIME  
library.  The data returned by the library is not changing according  
to the API (I'm assuming the API in this example states something  
like: @return string A MIME encoded string).  The API guaranteed a  
MIME encoded string, which it returns.  What that string looks like on  
a byte-to-byte level is irrelevant and not guaranteed.  Any  
application that assumes anything about the content of the data, other  
than the fact it is an encoded string, is wrong.

> It is VERY frustrating as a developer to have your code break after  
> some minor update to a library not under your control. As an  
> example, at one point ImageMagick's utilities were breaking BC with  
> almost every minor (and even with only revision number increments)  
> release they made. They, too, had made arguments that the previous  
> behavior was not totally correct.

But IIRC, Imagemagick was changing the API itself.  In my example  
above, and in the Horde Registry example), the API didn't change.  The  
MIME library returned correct data both before/after the change.  The  
Horde Registry never guaranteed that init() would be called with a  
fully available Horde framework.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]