[dev] [commits] Horde branch master updated. 760524934f11365acac54b36a4ced40996062ebe

[Jan Schneider]

Zitat von Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Michael J Rubinsky <mrubinsk at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Michael J Rubinsky <mrubinsk at horde.org>:
>>>
>>>> Quoting Jan Schneider <jan at horde.org>:
>>>>
>>>>
>>>>> This doesn't necessarily mean that we aren't allowed to bump a  
>>>>> major version of a library inbetween major releases of Horde. If  
>>>>> for example Horde_Imap_Client 3.0 would have been ready for IMP  
>>>>> 6.2, we could release it, and make it a requirement in IMP. The  
>>>>> problem is, and that's a good example of the general problem of  
>>>>> decoupling libraries from Horde major versions: Since 3.0 is API  
>>>>> incompatible to 2.x, *all* apps and libraries of  
>>>>> Horde_Imap_Client would have to be updated to the new API.  
>>>>> Otherwise users of, say IMP and Horde_ActiveSync cannot upgrade  
>>>>> at all.
>>>>
>>>> I would argue against this. It's a very dangerous precedent to  
>>>> set. With Horde_Imap_Client, we might be able to get away with  
>>>> every library that uses it also upgrading to the new API, but  
>>>> that can lead down a very slippery slope - every one of those  
>>>> libraries would need to be major version bumped too, making a  
>>>> large number of our libraries potentially not API compatible  
>>>> withing the same major version.
>>>
>>> Why? Just because a library uses a different major version of  
>>> another library, doesn't mean that it has to bump its major  
>>> version too.
>>
>> True. I guess I was assuming that the API of the new library would  
>> change to for some reason. Obviously this is not correct.
>
> This is what I was thinking of:
>
> Horde_Imap_Client is bumped to 3.0, and IMP is updated to require  
> it. This breaks the API for Imap_Client. Horde_ActiveSync is not  
> updated, and remains at version, let's say 2.4.0. The user updates,  
> but since Horde_Imap_Client does not depend on Horde_ActiveSync (nor  
> does IMP), we can't enforce a new Horde_ActiveSync minimum version  
> so the upgrade proceeds. The system now has an installation that has  
> a working IMP, but a completely broken ActiveSync implementation -  
> with no obvious reason to the user why.
>
> Horde_ActiveSync OPTIONALLY requires Horde_Imap_Client (up to, but  
> not including Horde_Imap_Client 3.0), but the opposite is not true.  
> Will pear block the installation if the dependency is optional?

Yes.

> Of course, Horde_Core OPTIONALLY requires both of these libraries as  
> well. I'm sure we could figure out a combination of dependency  
> changes in Core and/or IMP that would force this to work, but that's  
> not the point. The point is that some libraries have an optional,  
> one way, dependency that may not block an installation from  
> proceeding. Or will pear block the upgrade if the dependency is  
> optional?

It does.
-- 
Jan Schneider
The Horde Project
http://www.horde.org/