Robert Ramey wrote:
a) designate an branch/trunk as the "Current Release".
That's what I'm referring to as 'stable'. The question is what that gets created from, since it doesn't exist, yet.
b) ALL development occurs on branches.
I'm not sure what that means, given how subversion handles branches. The difference between 'trunk' and 'branches/something' is only in the naming.
c) Testing is applied to branches as requested.
I believe how test runs are triggered most efficiently depends on the usage patterns. Ideally (i.e. with infinite resources), test runs would be triggered on each change. If that isn't possible, alternative approaches can be chosen, such as 'no earlier than x minutes after a checkin', to allow developers to make multiple connected checkins in a row (though with subversion there shouldn't be any need for that, in contrast to cvs). Or, "triggered by checkins but no more frequent than once per day". Etc. (See http://buildbot.net/repos/release/docs/buildbot.html#Schedulers)
d) At the discretion of the release manager, Development branches are merged into the "Current Release" and the whole system is tested.
Does this imply that each individual feature (as defined by something that is meant to be merged into 'stable' as a whole) will be developed in isolation, on its own branch ? I'm not sure how practical that would be. In any case, I agree to the point that there should be relatively few, but coarse grained, checkins on the 'stable' branch, which can be backed out as a whole if any regressions occur.
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.
As above, I'm not sure what the tag is good for, with a repository that has atomic / global revisions. Just remembering the revision number that contains a new feature the first time should be sufficient. Packaging automatically (after a successful test run) can and should be automated with buildbot, too. So, in this light, the release manager's job would be to decide which patches / features to merge from development branches to stable, based on the current release's life cycle.
If you had nothing else to do, you could make the "Current Release" /main/trunk etc ONLY updateable by the release manager. Who would do this by merging in branches which have passed their tests. Then we'd be in business
Actually I don't think it is practical to have a single person do all this. That would create a huge bottleneck. The most important thing to do is formalize the development process as far as version management is concerned, to be able to easily and quickly rollback anything that risks to destabilize the stable / release branch. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...