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

[Michael J Rubinsky]

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.

>> Isn't this one of the reasons we exclude the next major version in  
>> the package.xml dependency list?
>
> No, this is to enforce semantic versioning onto the dependency resolution.
>
> Another issue comes to mind though: we experienced this already with  
> Horde 4 -> 5. PEAR is not smart enough to upgrade within a major  
> version, if there are both major and bugfix version updates of a  
> package, but the major version has unresolvable dependencies. This  
> means that people are not only stuck within a minor version if a  
> dependency cannot be resolved, they are also stuck within the  
> *exact* version they happen to have installed when we release a new  
> major version of a package. Granted, this is PEAR's fault, not ours,  
> but it will affect our users nonetheless.

This also seems like something that would be fairly messy with our  
monolithic rep (keeping different maintenance branches for each  
library). So, probably not something to start messing with until we  
split.

> I'd like to check if a separate PEAR server could help with this  
> situation, once we release Horde 6.

That's an interesting idea.

> Anyway, I agree that there are all kind of problems with releasing a  
> new major version of a package outside of a major horde version  
> bump, but for certain libraries this might be handleable.

Ok. Case by case then.


-- 
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/7a497d6e/attachment-0001.bin>