I think that a tag would be good but please _not_ anything that suggests 0.6.9. 
 I would really like to see us reserve version numbers for proper releases that 
have undergone the release candidate procedure.


d...@metaverseink.com wrote:
> +1
> 
> Mic Bowman wrote:
>> Can I make one request... Can we tag the current master as 0.6.9 (or 
>> something) prior to the merge?
>> --mic
>>
>>
>> On Mon, Feb 22, 2010 at 8:13 AM, <d...@metaverseink.com 
>> <mailto:d...@metaverseink.com>> wrote:
>>
>>     We can, by this order:
>>     1) merge presence-refactor into master
>>     2) create a sop-refactor branch from master immediately after
>>     3) create a 0.7 branch some time later
>>
>>     I would like to propose that the sop refactoring work be done in a
>>     branch rather than in the master branch, similar to what we did for the
>>     services refactoring. It works pretty well -- gives the refactoring devs
>>     peace of mind to leave things unstable and isolates the master branch
>>     from prolonged instability.
>>
>>     Also, are there any suggestions for Adam before he starts doing this? He
>>     sent out a document some time ago, but there wasn't a lot of feedback or
>>     discussion. Are there any alternatives or wishes for his proposed work?
>>
>>     Justin Clark-Casey wrote:
>>      > Frisby, Adam wrote:
>>      >> 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?
>>      >
>>      > 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.
>>      >
>>      > 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?
>>      >
>>      > 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.
>>      >
>>     _______________________________________________
>>     Opensim-dev mailing list
>>     Opensim-dev@lists.berlios.de <mailto:Opensim-dev@lists.berlios.de>
>>     https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 


-- 
Justin Clark-Casey (justincc)
http://justincc.org
http://twitter.com/justincc
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Reply via email to