On 8/1/07, Robert Ramey <ramey@rrsd.com> wrote:
The thrust of Beman's proposal is actually quite simple. It consists of
a) designate an branch/trunk as the "Current Release". b) ALL development occurs on branches. c) Testing is applied to branches as requested. d) At the discretion of the release manager, Development branches are merged into the "Current Release" and the whole system is tested. e) Each time the "Current Release" test passes more tests than the previous one, A tag is added by the release manager and a new download package is automatically created. I would anticipate this happing about once/month.
Has anyone tried this before, or know anyone that has? Like maybe the Photoshop team? Maybe you can bug Sean for details. The Premiere team is trying a version of this as well, but we are just starting out, so I can't give any useful feedback yet. Maybe if you guys take a long time to discuss it, we can ship a version of Premiere before you decide, and I can give you feedback then :-).
From what I know from PS's CS3 release, the system mostly worked. There was at least one big checkin to main that broke a seemingly unrelated component, and all heck broke loose. I'm not sure why the change wasn't noticed when the branch pre-merged main INTO the branch before merging into main, but I think it was because they allowed checkins into main to overlap. To avoid that, the Premiere team is going to schedule checkins to main very carefully, so that only one branch is checking in at a time.
We also have only 3 or 4 branches, with 3 or 4 people per branch ('feature groups'), not a ton of separate developers. And we only check into main when a feature is done and shippable, not just stable. But that might not be much of a distinction for library code. I do think you may find things work better/worse for different types of libraries - ie 'core' libs vs leaf libs, but that's just a guess. Tony