[dev] [commits] Horde branch FRAMEWORK_5_0 updated. 450bba25ab112a31ff062869971d780fd011f8f5

[Michael M Slusarz]

Quoting Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting "Michael J. Rubinsky" <mrubinsk at horde.org>:
>>
>>> commit 70a25e2194fc5e790cebf3c18491d2a319b70395
>>> Author: Michael J Rubinsky <mrubinsk at horde.org>
>>> Date:   Tue Apr 16 16:54:29 2013 -0400
>>>
>>>   Bug: 12185 Fix bad cherry-pick.
>>>
>>>   Horde_ActiveSync_Device is not present in FRAMEWORK_5_0
>>>
>>> framework/ActiveSync/lib/Horde/ActiveSync/Connector/Importer.php |    3 +--
>>> 1 files changed, 1 insertions(+), 2 deletions(-)
>>>
>>> http://git.horde.org/horde-git/-/commit/70a25e2194fc5e790cebf3c18491d2a319b70395
>>
>> My question is why are *ANY* framework commits being made to  
>> FRAMEWORK_5_0 at this time.  This doesn't make sense.  Framework  
>> code is not tied to 5.0 (or any other Horde version for that matter).
>
> Plus, framework code is absolutely tied to a Horde release in so far  
> as it needs to maintain BC withing a single major version. So, how  
> is any library, as it exists in FRAMEWORK_5_0, NOT tied to a  
> specific Horde release (Horde 5.x)?

No it's not.  How is horde (the application) tied to any framework  
package version?  For example... Horde (the application) can run any  
version of Horde_Core 2.  We might release Horde_Core 2.99.99 4 years  
from now with code stored in an "obsolete" branch.

The fact that framework code lives in the same repository as  
application code must not be confused with some sort of idea that  
those two codebases are somehow compatible.  Just because it *has*  
worked up to this point is irrelevant - that's mainly been done to  
ease development setup.  But from a theoretical standpoint, this is a  
misnomer.

For example, I should (and want to) be able to release IMP 5.1 to work  
with Horde_Imap_Client 3.0.  But there is no need to force, for  
example, Horde 5.1 to use 3.0.  These are perfectly valid development  
decisions and sort of the whole reason why we are using PEAR  
packaging.  Will this setup work running directly out of the git repo?  
  No.  That **SHOULD** be irrelevant.  The fact that it isn't proves  
that our current repository setup is wrong - we are being limited in  
what we can do by artificial boundaries.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]