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

[Michael J Rubinsky]

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? 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?
-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5849 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/dev/attachments/20131022/f6175c0b/attachment.bin>