On Fri, 01 Jul 2011 18:37:27 -0300, David Bremner <[email protected]> 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. -- [email protected]
pgp61N9gvwlc0.pgp
Description: PGP signature
_______________________________________________ notmuch mailing list [email protected] http://notmuchmail.org/mailman/listinfo/notmuch
