On 1 July 2011 19:47, David Bremner <david@tethera.net> wrote: > On Fri, 01 Jul 2011 14:48:24 -0700, Keith Packard <keithp@keithp.com> wrote: >> > 2) merge master onto the release branch >> >> This makes doing 'bug fix' stuff on top of 0.6 a bit more challenging. > > Can you elaborate? Naively it seems like one ends up with the same kind > of spur of history off of the 0.6 tag in both cases. > > ----.--------------master > \ > ---- 0.6 ---- bugfix > > versus > > -----.----------. > \ \ > ---- 0.6--------master > \ > ----- bugfix > >> As an alternative, you probably should have simply put non-release >> patches on a separate 'feature branch' (probably residing in the feature >> author's repository) which would then be merged onto master post-0.6 > > Yes, that is certainly nice from a git history point of view. On the > other hand the point of separating the roles of feature merger from > release mechanic was to allow Carl more time to work on merging features > into master, and I'm not sure how turning master over to the release > manager helps that. 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). This workflow would keep a nice useful history while allowing even more independence between the feature merging and release process, what do you think? Servilio [1] Or next, or whatever other name is better understood by the community.