On Jan 5, 2010, at 10:33 AM, Quanah Gibson-Mount wrote:
--On Tuesday, December 22, 2009 7:40 PM -0800 Howard Chu hyc@symas.com wrote:
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 -> HEAD.
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.
-- Kurt