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

[Jan Schneider]

Zitat von Michael J Rubinsky <mrubinsk at horde.org>:

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

I think Michael R. is right, but I also understand where the confusion  
comes from.

We actually had a topic branch for the new ActiveSync stuff, and if I  
hadn't merged it into master along with the *_*_1 branches, this whole  
discussion wouldn't exist.
Michael S. is right that this isn't *technically* coupled with the  
Horde 5.1 release, but as R. pointed out, it's still semantically  
coupled because of (loose) inter-dependencies and I agree it's a good  
idea to run the release process with beta testing of the AS 2.4.0  
version along with the Horde 5.1 beta testing.

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