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

[Michael J Rubinsky]

Quoting Michael M Slusarz <slusarz at horde.org>:

> 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.

Right. So I would say that Horde (the application) is tied to (major)  
version 2.x of Horde_Core. Your statement that framework code is not  
tied to ANY horde version is incorrect.

> 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.

No. Major versions of FRAMEWORK_X libraries MUST be compatible with  
version X of Horde. We can't make a BC break in any major library  
version that is part of FRAMEWORK_X.


> 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.

Well, in my case there is. Horde 5.1 REQUIRES Horde_ActiveSync 2.4.0  
as there are additions to the ActiveSync API that are being called  
from Core. This is allowed in our model. Applications can requires  
whatever arbitrary minor version of a framework library that it needs.

>  These are perfectly valid development decisions and sort of the  
> whole reason why we are using PEAR packaging.

Right, and making bug fix commits to current, most recent, stable  
branch before the next minor version is complete doesn't go against  
this statement.

>  Will this setup work running directly out of the git repo?  No.

I say it should. There should be no reason that master (or  
FRAMEWORK_X_Y) should not work directly from a checkout. We absolutely  
should NOT be making any BC changes to code within a branch that is  
not a new major version, at least not in our current branching model.

> 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.

Whether this is true or not is irrelevant to the current discussion  
though. Today, the branching model is what it is. Today, I want to  
release a bug fix. I therefore have to deal with the repository (along  
with whatever restrictions it may have) as it is *today* - not how it  
would be in a perfect world.
-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-keys
Size: 2200 bytes
Desc: PGP Public Key
URL: <http://lists.horde.org/archives/dev/attachments/20130416/ed5da2fc/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6062 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.horde.org/archives/dev/attachments/20130416/ed5da2fc/attachment-0001.bin>