[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: OpenLDAP 2.5

--On Friday, January 08, 2010 5:18 PM -0800 Kurt Zeilenga <Kurt@OpenLDAP.org> wrote:

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>

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 Gibson-Mount
Principal Software Engineer
Zimbra, Inc
Zimbra ::  the leader in open source messaging and collaboration