On Jan 11, 2010, at 10:49 AM, Quanah Gibson-Mount wrote:
--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 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.
Regression risk is huge here. If you always commit to trunk first, your regression risk is low.
Also, you never have to forward port, only back port.
And you can test on trunk and only bring onto the branch after the patch has been determined to be releasable. This improves stability of the release branches.
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.
Our hot fixes are just another release.
As I noted, this type of stuff is likely very overkill for the project.
I think it problematic model (release branch first) in general. With todays concurrent development practices and shared engineering responsibilities, trunk first (IMO) is better.
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.
That's because you (not us) want to be able to do hot fixes for any release. But as long as you have a tag, you can subsequently branch. We always tag releases. We've never had a need to branch off those tags.
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.
Right. But you did suggest we consider it. I note that I did consider this ages ago (when I set up the repo) and rejected it.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration