This approach works for me - I am not commited to any particular system, and the more compatibility can be preserved, the better. It also addresses my other principal concern, that of granularity. That being said, we still have not addressed the issue of the region that is already registered with the grid - where does this case fit into the picture?<br>
<br>As for a sunday release, unless miracles happen in the stability department in the interim, I think that sunday may be a bit aggressive. Perhaps the following sunday might be more realistic. Again, it all comes down to stability. If we are reasonably stable by this sunday, that would be great, and I'd be willing to endorse a release. If a week past sunday we are still similarly unstable, I think a release would be a mistake then as well.<br>
<br>I think we need to remember that as developers, we drive the releases, the releases dont drive us.<br><br>Cheers!<br>James<br><br><br><div class="gmail_quote">On Wed, Nov 5, 2008 at 10:20 AM, Charles Krinke <span dir="ltr"><<a href="mailto:cfk@pacbell.net">cfk@pacbell.net</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;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 12pt;"><div>This seems eminently reasonable to me also.<br>
<br>On the 0.6 front, I would like to aim for this coming Sunday to tag svn for a 0.6 release and start the cycle of zip/tarball and binaries for download. As a consequence, this week needs to be one of reliability and stability testing. <br>
<br>We had a few problems last week with freezes of regions and this appears to be getting better. <br><br>This is the time to push for stability as we head towards Sunday with a few to how to minimize support issues on both this channel and our IRC.<br>
<font color="#888888"><br>Charles<br></font></div><div><div></div><div class="Wj3C7c"><div style="font-family: arial,helvetica,sans-serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;">
----- Original Message ----<br>From: Sean Dague <<a href="mailto:sdague@gmail.com" target="_blank">sdague@gmail.com</a>><br>To:
<a href="mailto:opensim-users@lists.berlios.de" target="_blank">opensim-users@lists.berlios.de</a><br>Sent: Wednesday, November 5, 2008 7:28:42 AM<br>Subject: Re: [Opensim-users] [PROPOSAL]: Sim version filtering (was Re: Sim Version Filtering (re: Mantis #0002361...)<br>
<br>
Justin Clark-Casey wrote:<br>> PROPOSAL FOR SIM VERSION FILTERING<br>> <br>> Not being able to stop sim versions that implement obsolete comms interfaces from connecting to a grid is becoming an <br>> increasingly awkward problem. As you can imagine, it leads to a high volume of support requests, particular if the grid <br>
> is upgrading quite often (which is the case in large development test grids).<br>> <br>> There has been a proposal (in <a href="http://opensimulator.org/mantis/view.php?id=2361" target="_blank">http://opensimulator.org/mantis/view.php?id=2361</a>) to have the region server send its SVN <br>
> revision number to enable filtering by the grid server. However, I'm not a fan of this idea for the reasons outlined in <br>> the e-mails further below (ties us into a source control system, not necessarily present in binaries/source, not <br>
> friendly to non OpenSim implementations).<br>> <br>>
Therefore, I am going to propose that there is an interface version number in <a href="http://OpenSim.Framework.Servers.VersionInfo.cs" target="_blank">OpenSim.Framework.Servers.VersionInfo.cs</a>. <br>> This is separate from the OpenSim version, and would increase by 1 every time a change was made to OGS1 or interregion <br>
> interfaces that was incompatible with older versions.<br>> <br>> So the sequence would be 1, 2, 3, 4, ...<br>> <br>> On region connection, the version number would be sent. If it differs from that of the grid, the grid would refuse <br>
> connection with a message advising version upgrade (or possibly downgrade)<br>> <br>> The advantages of this approach are that<br>> <br>> a) We don't use the SVN revision number<br>> b) Grid operators don't have to manually determine which regions are compatible<br>
> <br>> The disadvantages are<br>> <br>> a) Developers
have to upgrade the number themselves. I don't believe this is a huge burden. It's also not a disaster <br>> if this is forgotton - one just upgrades it on the next commit.<br>> <br>> This may be the simplest thing that could possibly work whilst avoiding the disadvantages of using the SVN number. One <br>
> can get more elaborate (e.g. minor verion numbers for compatible changes) but I don't think the complication is <br>> worthwhile or known to be workable at this point.<br>> <br>> Comments?<br><br>+1 on this approach. I like not using svn version, as that restricts<br>
compatibility too much. I also think we'll have a good success rate at<br>figuring out that something is destabalizing change.<br><br>I'd *highly* suggest this goes in before 0.6, so that 0.6 regions<br>participate in this system. This will be important as a lot of people<br>
will probably go to 0.6 when it comes out and get off the
svn tracking<br>at that point.<br><br> -Sean<br><br>-- <br>Sean Dague / Neas Bade<br><a href="mailto:sdague@gmail.com" target="_blank">sdague@gmail.com</a><br><a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br><br></div></div></div></div></div></div><br>_______________________________________________<br>
Opensim-users mailing list<br>
<a href="mailto:Opensim-users@lists.berlios.de">Opensim-users@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-users" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-users</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>===================================<br>The wind<br>scours the earth for prayers<br>The night obscures them<br><br><a href="http://osgrid.org">http://osgrid.org</a><br>
<a href="http://del.icio.us/SPQR">http://del.icio.us/SPQR</a><br><a href="http://twitter.com/jstallings2">http://twitter.com/jstallings2</a><br><a href="http://www.linkedin.com/pub/5/770/a49">http://www.linkedin.com/pub/5/770/a49</a><br>