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

[Jan Schneider]

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.

> 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.
I'd like to check if a separate PEAR server could help with this  
situation, once we release Horde 6.

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.

>> Besides the technical reasons for keeping releases synchronized,  
>> there is another aspect: marketing. Horde 5 is keyword, as well as  
>> an eco system. Like Symfony2 is. If we want to encourage and  
>> propagate usage of Horde libraries, we must not get developers into  
>> dependency hell or having to learn different APIs or coding  
>> standards.
>>
>> The release of Horde_Socket is spilt milk now though. I'm not a  
>> friend of pulling releases, and I don't think releasing 2.0 without  
>> namespace, just to release 3.0 with namespaces again, once we  
>> namespace all libraries, is a good option either.
>
> Agreed.


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