branchs and tags and merges oh my!

[Keith Packard]

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>