[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: [dev] [commits] Horde branch master updated. 70ad1361e25088ff5cf8f2a2b6de9ec792bce3cf Jan Schneider Thu Feb 16 03:00:35 2012

Zitat von Ralf Lang <[EMAIL PROTECTED]>:

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

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

Horde developers mailing list
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: [EMAIL PROTECTED]