<!DOCTYPE html><html><head><title></title><style type="text/css">
p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Wed, Nov 6, 2019, at 10:56 AM, Bron Gondwana wrote:<br></div><blockquote type="cite" id="qt"><div style="font-family:Arial;">On Wed, Nov 6, 2019, at 09:24, ellie timoney wrote:<br></div><blockquote id="qt-qt" type="cite"><div>On Tue, Nov 5, 2019, at 4:44 PM, Bron Gondwana wrote:<br></div><blockquote type="cite" id="qt-qt-qt"><div style="font-family:Arial;">On Tue, Nov 5, 2019, at 12:04, Ricardo Signes wrote:<br></div><blockquote id="qt-qt-qt-qt" type="cite"><div>So, I think the plan was to cut a stable Cyrus 3.2 after we had stable JMAP. Is that time now? We talked about this on the Zoom call today.<br></div></blockquote><div style="font-family:Arial;"><br></div><div style="font-family:Arial;">I think we're pretty close to it. The big question is: do we fork what will eventually become 3.2 and keep stabilising on it while we ship UUID mailboxes on master, or do we finish 3.2 before we merge uuid mailboxes.<br></div></blockquote><div><br></div><div>I don't think we can include uuid mailboxes in 3.2 -- it's too new/untested, whereas this is a "stable release". (But I don't think you were proposing this.)<br></div></blockquote><div style="font-family:Arial;"><br></div><div style="font-family:Arial;">No - the idea is to fork 3.2 just before uuid mailboxes lands. The question is:<br></div><div style="font-family:Arial;"><br></div><div style="font-family:Arial;">1) fork now, put all other fixes on both branches.<br></div><div style="font-family:Arial;">2) do the 3.2 prep work first on master, then fork that before merging uuidmailboxes.<br></div><div style="font-family:Arial;"><br></div><blockquote id="qt-qt" type="cite"><div>Whether we fork the 3.2 branch now, or wait until we're closer to releasing it, doesn't really matter to me. Though if we have a bunch of stuff we're still stabilising, it's always easier to do that work on master only rather than juggling it on two branches. But either way, it does mean the mailboxes-by-id branch needs to keep sitting on the side and being rebased until after 3.2 becomes its own branch.<br></div></blockquote><div style="font-family:Arial;"><br></div><div style="font-family:Arial;">Yeah, that's the challenge isn't it :) Which is less work / safer / more understandable.<br></div></blockquote><div><br></div><div>Once we land mailboxes-by-id on master, I think there's gonna be a lot of big differences between 3.2 and master, which will make fixes-on-both a nuisance (no easy cherry-picks). So I think I've convinced myself we need to get 3.2 to a place we're happy with first, to avoid all the duplication.<br></div><div><br></div><div>Though... I suppose the same duplication happens anyway, but in the form of rebases to the mailboxes-by-id branch instead... <br></div></body></html>