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 fixes. 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. - Volodya