|
Boost : |
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2007-08-03 10:36:44
On 8/1/07, Robert Ramey <ramey_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk