<div>Mic,</div><div><br></div><div>It seems like a good request. I like the idea of a tag, but maybe we should create two tags? Use a 0.6.8.x tag prior to the merge, and a 0.6.9.x tag after the merge? Then save the 0.7 tag for the stable RC?</div>
<div><br></div><b><i>> Can I make one request... Can we tag the current master as </i></b><div><b><i>> 0.6.9 (or something) prior to the merge? <br></i></b><br><div>Maybe just tag the current master as a 0.6.8.x prior to the merge, then just create a 0.6.9.x tag after the merge?</div>
<div><br></div><div>That way we have two tags (a 0.6.8.x tag prior to merge and a 0.6.9.x tag after merge).</div><div><br></div><div>Then we can work on bug testing, and bug fixing and then decide which of the two tags we'll use for the 0.7 RC. If the merge breaks too many things, or is too unstable we can just revert to the 0.6.8.x tag series.</div>
<div><br></div><div>If the merge doesn't hurt/damage things too badly, and the fixes can all be done fairly easily, then we can use the 0.6.9.x tag to use for a 0.7 stable RC for the final release candidate (after it goes through the whole formal RC bug-testing/bug-fixing release candidate process).</div>
<div><br></div><div>This way at least we have two separate tags (0.6.8.x and 0.6.9.x) that we can use as tagged reference points for testing, prior to the 0.7 RC?</div><div><br></div><div>This way the current state could be tagged as a 0.6.8.x tag, then we can use 0.6.9.x for: </div>
<div><br></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">1) merge presence-refactor into master<br>2) create a sop-refactor branch from master immediately after</span></div>
<div><br></div><div>Then depending on how much work needs to be done after the merge of "presence-refactor" into master, and the "sop-refactor" branch work that needs to be done. This way we can have two separate tagged releases that we can use for bug testing and bug reporting. Then depending on how much is broken (and what the timeline is to fix the bugs) then we'll either just use either the 0.6.8.x tag (pre-merge) or the 0.6.9.x tag (post merge) for the stable 0.7 RC.</div>
<div><br></div><div> Mark</div><div><br></div><div><br><div class="gmail_quote">On Mon, Feb 22, 2010 at 10:20 AM, Mic Bowman <span dir="ltr"><<a href="mailto:cmickeyb@gmail.com">cmickeyb@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Can I make one request... Can we tag the current master as 0.6.9 (or something) prior to the merge? <br><font color="#888888">--mic</font><div>
<div></div><div class="h5"><br><br><br><div class="gmail_quote">On Mon, Feb 22, 2010 at 8:13 AM, <span dir="ltr"><<a href="mailto:diva@metaverseink.com" target="_blank">diva@metaverseink.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">We can, by this order:<br>
1) merge presence-refactor into master<br>
2) create a sop-refactor branch from master immediately after<br>
3) create a 0.7 branch some time later<br>
<br>
I would like to propose that the sop refactoring work be done in a<br>
branch rather than in the master branch, similar to what we did for the<br>
services refactoring. It works pretty well -- gives the refactoring devs<br>
peace of mind to leave things unstable and isolates the master branch<br>
from prolonged instability.<br>
<br>
Also, are there any suggestions for Adam before he starts doing this? He<br>
sent out a document some time ago, but there wasn't a lot of feedback or<br>
discussion. Are there any alternatives or wishes for his proposed work?<br>
<br>
Justin Clark-Casey wrote:<br>
> Frisby, Adam wrote:<br>
>> I would like to start the SOP refactor fairly soon - what if once 0.7 is tagged for the RC process; I go and and make a new branch; we can sic testers on the presence-branch, while dev happens on the branch I tag?<br>
><br>
> My concern with branching for 0.7 release candidates immediately after the presence-refactor merge is that we won't get everybody helping to iron out the inevitable hiccups since most people follow master. Waiting a couple of weeks for at least some of this to happen is the minimum, I feel. Ideally, I'd like that to be longer but I know that you and other folk want to press ahead.<br>
><br>
> I guess some of this depends on how disruptive the refactor is. What do you think? I'm assuming there will be breakage but perhaps I'm wrong?<br>
><br>
> Of course, I guess you could create a separate sop-refactor branch at any point and start work there, possibly merging back to master and continuing in master once 0.7 RC has been branched.<br>
><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</blockquote></div><br>
</div></div><br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div><br></div></div>