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

[Gunnar Wrobel]

Zitat von Michael M Slusarz <slusarz at horde.org>:

> 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.

Of course you right on the technical level. If the API definition was  
100% precise and easy to understand for the downstream developers then  
changing the content of the return value within the boundaries defined  
by the API does not warrant a BC break.

But I also understand the other argument. If the downstream developers  
that consume the API have all been too dumb to get it right and every  
single application written against that library suddenly breaks  
because of the upstream change - wouldn't it be nice of upstream if  
they'd bump the major version?

I don't think it will be easy to draw hard lines here. Concerning our  
current situation I think we can all more or less agree with switching  
the major version and fix the issues that we currently see. It will  
certainly have the advantage of making the next major version of our  
API more robust and easier to consume but people that want to develop  
based on Horde. Which would be good.

Cheers,

Gunnar

>
>> 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]
>
> -- 
> Horde developers mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org

-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de