From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-08-02 12:39:24
Robert Ramey 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.
Okay, say somebody reports a bug in program_options that I fix
(on a branch named program_options_one_line_fix_127). Say the same
somebody reports a bug in a future library, and the author immediately
fixes that (on a branch named future_one_line_fix_777). Now the user
has to grab stable branch and perform two merges manually to get both
Not to mention that if every one-line change is gated via release
manager, it creates a bottleneck we don't presently have. While
it's good to be able to test specific branch, I doubt requiring
all changes to be done on branch is so great idea.
> The only things we're missing right now are c) - which I believe will be
> doable in the near future. And a set of "best practices" for for
> developers and the release manager. This is just a question of agreeing
> on how to use SVN as regards branches.
> If you had nothing else to do, you could make the "Current Release"
> /main/trunk etc ONLY updateable by the release manager.
This is one-line change in Subversion config, I'd suspect.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk