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.
No. The integration process from HEAD -> branch is manual. Thus commits for any feature can go to HEAD, but only those features going into the branch get migrated over. Once the branch is frozen for features, then fixes go from branch -> HEAD.
Our current practices allow developers to generally move forward without regard to what's happening on release branches.
Same here. Except that we sometimes have 3 branches of work occurring (HEAD, most current release, release - 1) due to support reasons.
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.
Because we have customers to support, which sometimes requires hot fixes to an old release (sometimes several releases back) where we integrate a single fix to that release branch, rebuild the binaries, and give it to them. As I noted, this type of stuff is likely very overkill for the project.
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.
There are a number of reasons why this approach is taken. We didn't use to make release branches, and it was a nightmare not to. The development requirements and process for Zimbra are substantially different than what is needed for OpenLDAP which is why I noted this was likely a bit overkill.
--Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration