On Jan 5, 2010, at 10:33 AM, Quanah Gibson-Mount wrote:
--On Tuesday, December 22, 2009 7:40 PM -0800 Howard Chu
> With 2.4.21 out, and hopefully stable enough to promote to the next
> Stable release, it's time to feature-freeze 2.4 and prepare for the 2.5
> branch. As I already announced to the OpenLDAP-Committers, we're also
> planning to switch from CVS to GIT in mid-January. Commits for 2.5 will
> begin after we've settled into GIT.
Yeah! One question from the RE side, is how to best handle 2.4 fixes with HEAD getting
further & further apart.
At Zimbra, what we do is integrate from HEAD -> branch while development/features are
in parallel. Once the branch is feature frozen, the integration is from branch ->
This implies that only features suitable for the branch can be committed because you would
never commit to a branch code that was not intended to be released there. This approach
also tends to lead to regressions.
Our current practices allow developers to generally move forward without regard to
what's happening on release branches. Release engineers can pick and choose what to
bring over on a per branch basis. And, yes, as branches diverge from trunk, back porting
gets harder and harder. The response to this is to cut off support for older branches as
they diverge too far. This is why we've always had the "at most two release
branches at once" rule. One branch, the young branch, would be mostly following
trunk. The old branch would be feature frozen and, at some point, restricted to only
security and other critical bug fixes (and eventually moved to historic).
I've already run into a few cases with RE24 where I had to ask
Howard to do the integration, because the code was very different, and it's only going
increase from here on out.
The significant divergence between 2.4 and head is a sign its time to start a 2.5 branch
so that one can further restrict what goes on 2.4. These restrictions both stabilize 2.4
but reduce the back porting.
One other thing Zimbra does is create specific branches for every release. In equivalence
for OpenLDAP, that'd be a 2.4 branch plus a branch cloned off of it for every release
(like 2.4.20 branch, etc).
Why? You only need a branch if you're going to do releases off of it.
We only make the release branch when we're at "code
freeze" for a given release. This allows developers to continue to make changes to
the trunk of that branch without affecting the upcoming release.
We simply allow developers to continue work on HEAD while releases are being prepared.
There's little need to freeze trunk.
Any fixes we deem "release critical" then get integrated
into the newly formed release branch.
That may be a bit overkill for this project, but thought I'd note it.
The approach is so 1970s.