[dev] [commits] Horde branch master updated. 70ad1361e25088ff5cf8f2a2b6de9ec792bce3cf

[Jan Schneider]

Zitat von Ralf Lang <lang at b1-systems.de>:

>> The problem comes with something like fixing an issue on the x.1 branch,
>> testing the fix, and then deciding that the fix should be backported.
>> What happens now is that you can grab the fix from the x.1 branch (via
>> git cp). However, it is likely that the fix isn't going to apply
>> cleanly. Then you make the modifications in x.0 and commit. However, you
>> eventually have to re-merge this fix back into develop, which breaks
>> everything.
>
> That's why I usually check in fixes to master - they get propagated  
> to develop, mostly without any additional work. This is probably the  
> wrong way. Otoh, I did not know the develop branch always is (or  
> should be) in a working state. I expect the "HEAD" branch to have  
> broken features every now and then. I usually develop minor bug  
> fixes against maint, sometimes even against a snapshot of the  
> production environment and bring it into git step by step later.

Applying fixes to master is exactly the correct way. Like you said  
they are merged back into develop anyway, no cherry-picking necessary.
Beside that, if you actually develop the fix in master, chances to  
break something are much smaller, as if you develop the fix in another  
branch, and then only switch to master for cherry-picking, but without  
really *using* master.

That being said, as soon as we nearing the release cycle for H4.1, we  
will indeed branch off H4.0 and stabilize H4.1 in master. I guess it's  
just a matter of timing. If you rather develop new features, it would  
be easier if you wouldn't have to do this in a branch. If you are more  
into fixing bugs, it makes perfect sense to keep master the stable  
branch as long as possible.

>> If set up with x.1 as master, in this scenario we could have
>> cherry-picked the fix into the x.0 branch - do any additional fixes -
>> and that would be it. No worries about having to merge it back into
>> master. Cherry-picks would work the other way also.
>>
>> The days of bulk merging are probably over. Don't know about others, but
>> I no longer do any new features on x.0 - it is bugfixes only, and
>> generally after I fix them on develop.
>>
>> The bigger issue is probably the fact that it becomes tough (if not
>> impossible) to "version" the various applications when everything is
>> lumped together in a single repo. E.g. IMP 5.0 is done (from a
>> development standpoint) but Hermes hasn't been released yet and probably
>> shouldn't be in develop.
>>
>> Maybe what I am trying to say is: we might need to revisit the idea of a
>> git-repo for every application (not to mention every framework package).
>> That's really the only way to keep this all clean and correct.
>
> At least separating framework, horde base and apps would help.  I  
> don't see the benefit of checking out 80+ git repos just to get a  
> working develop/test installation of horde + my app under test. But  
> I don't really need folks and ansel around either when I'm looking  
> at, say, kronolith or sesha.

Yes, we should indeed revisit this after the 4.1 release.
-- 
The Horde Project
http://www.horde.org/