On 2 July 2011 13:30, David Bremner <david@tethera.net> wrote: > On Sat, 2 Jul 2011 11:59:04 -0400, servilio <servilio@gmail.com> wrote: >> What about having Carl do the merging of features into a develop >> branch[1], then the release manager prepares a release in a release >> branch, merging back and tagging into master when release is ready? A >> similar workflow could be followed for bugfix releases (branch to >> bugfix/release branch, prepare, merge back to master, tag). > > We could also call the develop branch "master" and use something like > "release" for the branch that contains the release history. I like this idea, two separate long-living branches for the releases and development. What branch would be the head of the master repository in this case? I'd prefer it to be "release", as it would provide the latest stable release when cloning. Also, in the name of the people that might want to build a stable version from source, preparing the release in a separate branch might be a good idea, merging the work there back to master when finished and into release to make the release. > This is is technically quite close to option #2, but perhaps conceptually > clearer (and throwing in Tom's tagging idea). > > 0.7-pre 0.8-pre 0.9-pre > -----.+--------------.+-------------.+------------- master > \ / / > --------. | / > \ / 0.7 / > +m------+-----+m--------+ release > 0.6 0.7.1 0.8 > > One difference in this version is that a merge from master onto release > (and convenience tagging of master) occurs only when we are ready to release. I think there is no need for tags on master, "make dist" should only be run on the "release" branch, right? Servilio