On Fri, 01 Jul 2011 18:37:27 -0300, David Bremner <david at tethera.net> wrote:
> 1) repeat the whole thing with a new release branch for 0.7 and end up > with > > ----------.--------------.------- master > \ \ > ----- 0.6 --- 0.7 That's the 'usual' plan followed by projects which use a central repository. > 2) merge master onto the release branch > > > -----------.--------. ----- master > \ \ / > ---------.--------.---- 0.7 > 0.6 now freeze This makes doing 'bug fix' stuff on top of 0.6 a bit more challenging. 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, in the 'merge window' plan. That's the usual plan followed by projects using multiple repositories and time-based releases. With this model, you simply release from master when the time comes. -- keith.packard at intel.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110701/4fa373ee/attachment.pgp>
