On Tue, 2008-08-05 at 15:06 +0100, Aidan Skinner wrote: > On Tue, Aug 5, 2008 at 2:41 PM, Alan Conway <[EMAIL PROTECTED]> wrote: > > > What I recall us saying is "don't until you really need one". We need > > one if there is any post-M3 work going on during the freeze. I'm working > > on clustering code that is well decoupled but still poses a risk of me > > breaking the C++ broker. There may be others working on post-M3 work as > > well. > > Is that something you need to land before M3 goes out? I guess ideally > you'd be doing this on a feature branch that tracks trunk, probably > easier with git than svn though. :/
I'm doing small incremental merges. The new functionality does nothing unless explicitly enabled so it doesn't interfere with non-cluster use of the broker. I prefer incremental merges to trunk (or some shared post-M3 branch) so that my code gets continuously integrated with any other work that is going on. > > I'd suggest we create an M3 branch and allow post-M3 work on trunk, > > merging M3 to trunk as we go. The alternative is to use trunk for M3 and > > create a post-M3-branch but that seems backwards to me. > > If you have to commit your stuff in the weeks between freeze and > release then yeah, that makes sense. The other advantage of an M3 branch over a frozen trunk is that it's unlikely anyone will accidentally commit post-M3 changes to an explicit M3 branch, which is always a risk with the trunk. Cheers, Alan.
