[Opensim-dev] Stable Branch pt III Was: RFC: Changing default script engine to xengine

Fri Dec 12 04:49:14 UTC 2008

The Major/minor/release concept is exhibited in the M.m.r notation.
Usually, the Major number is bumped at initial release and at major
structure or compatibility-affecting releases.  In this case, the
minor number being even (0.6) would be a 'stable', and odd (0.7) would
be 'development'.

Granted, what happens in Linux is Linus takes the last dev branch, and
generates release candidates.  Once he decides that it's stable
enough, he puts someone else in charge of the final stable release,
then bumps the version counters.

Under this scheme, the thing to do would be to take the 0.6 release
revision of SVN and branch from there to make 0.6, and then bump trunk
to 0.7.  Work on the 0.6 branch should relate only to stability and
relatively minor enhancements.  Work on the 0.7 branch should relate
to major overhauls.  (And note that the even-numbered kernels always
have more than one release.  What's Linux at now, 2.6.27?)

Going from 0.6 to 0.7 should always be possible.  Going from 0.7 to
0.6, though, not necessarily.  (If something breaks during the
overhaul of a feature's schema, there shouldn't be call to create a
schema-regression utility for those who were... special... enough to
run a production environment that keeps up with bleeding-edge
development.)

Erm... protocol changes.  If the protocol changes enough that there
needs to be something done in the even-numbered releases to make it
work with the development branch, that would be bad.  I think that:

- the protocol should specify what to do if the information is omitted,
- the protocol should specify a magic value to use to specify when the
information is omitted (hooray for Nullable<type>, it makes for easy
references to Null in an otherwise-limited type)
- the protocol should try not to break compatibility with the last
stable release branch

In general, I like LL's idea of implementing parallel code paths that
can be swapped between at runtime to perform the same function.  In
general, I also like the idea of being able to load assemblies into
the core at runtime, and I think that this would be an excellent
architecture to move toward.  (Especially if it can be unloaded at
runtime, as well.  This would provide a means to test on a 'live'
system without having to go through the full restart sequence.)

-Kyle H

On Wed, Dec 10, 2008 at 6:38 AM, Justin Clark-Casey
<jjustincc at googlemail.com> wrote:
> Stefan Andersson wrote:
>> Esteemed colleagues,
>>
>> It has been time to tag a stable branch for some time now.
>>
>> Since trunk is currently considered anything but stable, are people
>> feeling up for trying out branching a stable version before we do this,
>> and then actually work on that branch to stabilize it? (Merging back
>> changes to trunk where applicable of course)
>
> I dunno - I'm still not convinced that the project is mature enough to support stable branches, although I do think that
> this won't necessarily always be the case.
>
> I'm actually much more drawn to the idea that Adam proposed about a month ago (and which I was negative on at the time)
> that we start labeling odd minor versions as unstable and even versions as stable (please correct me if I misinterpreted
> this).  Therefore, when we tag 0.6.1 on the trunk this could perhaps be labeled as 0.6.1-unstable.
>
> The idea would be that the period between 0.6.1 and 0.6.2 would be as short as possible.  In that period we would
> refrain from making any changes that we think could destabilize the build, and preferably concentrate on those which
> would improve stability.  Once we're happy that the trunk is in a reasonable state then we would tag 0.6.2-stable and
> move on with the next set of somewhat riskier changes.
>
> On reflection this is very similar to a release candidate scheme, so perhaps this could be 0.6.1-rc and 0.6.1 instead
> for unstable and stable respectively.
>
> This scheme has the advantage of making it more likely that we do put effort into stabilization (since it isn't possible
> to plow on regardless with trunk and leave the stable branch in a siding).  We also know that there is some success in
> having people hold back big changes before a stable revision (as with 0.6.0).
>
> One disadvantage is that this probably wouldn't as controlled as a stable branch (since I would anticipate that we would
> still make normal changes that weren't purely aimed at stability unless we become much more disciplined that we have
> been historically).
>
> Also, this plays towards my biases for the agile methodology of always having a trunk that we can 'ship' and that
> approach of writing unit tests to help ensure more continual trunk stability.  Such a scheme may not suit your needs and
> I hope that OpenSim can pull in more stability patches that have perhaps been kept private out of technical necessity
> (not out of philosophy).  So I have no problem at all if we want to go ahead with trying to stabilize a branch, though I
> would be fairly concerned if this meant that trunk would become unstable for more extended periods of time.
>
>>
>> (It's not as hard as you think merging revisions, really - especially if
>> the revisions are reasonably local)
>>
>> It seems we really would need to create a still pool for the people that
>> just want to run their stuff.
>>
>> So, I propose we branch 0.6.1-stable but not necessarily tag it. Maybe,
>> at some point, we can tag 0.6.1 from this branch, and lo and behold, we
>> have (almost) had a proper release cycle!
>>
>> Best regards,
>> Stefan Andersson
>> Tribal Media AB
>>
>>
>>  > Date: Mon, 8 Dec 2008 18:23:24 -0500
>>  > From: sdague at gmail.com
>>  > To: opensim-dev at lists.berlios.de
>>  > Subject: [Opensim-dev] RFC: Changing default script engine to xengine
>>  >
>>  > This is a request for comments on changing the default script engine to
>>  > xengine. There was a thread about this a couple of months ago in which
>>  > the resolution was to wait until 0.6 was released.
>>  >
>>  > Here are the pros - cons as I see it:
>>  >
>>  > Cons
>>  > * a change like this, no matter how prepared we are, can cause some
>>  > temporary breaks in people's environments
>>  >
>>  > Pros
>>  > * xengine uses less memory than dotnet engine
>>  > * xengine uses less cpu than dotnet engine -
>>  > http://xyzzyxyzzy.net/2008/11/07/a-brief-look-at-dotnetengine-vs-xengine/
>>  > * xengine doesn't do the event drop which causes lots of bug reports
>>  > like this one: http://opensimulator.org/mantis/view.php?id=2777
>>  >
>>  > I'm sure there are other pros and cons, and I'm happy for others to
>>  > throw them out here. I've been telling every IBM internal team to use
>>  > XEngine for the past 6 months, and every one say a performance and
>>  > stability increase after they made the change.
>>  >
>>  > I think that making it the default out of the box will reduce a lot of
>>  > issues that new users are having with OpenSim, and it definitely along
>>  > the lines of trying to make as much work right out of the box as we can.
>>  >
>>  > Opinions? Comments? I'd like to try to achieve consensus over the next
>>  > couple of days so we could make such a change.
>>  >
>>  > -Sean
>>  >
>>  > --
>>  > Sean Dague / Neas Bade
>>  > sdague at gmail.com
>>  > http://dague.net
>>  >
>>  >
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> --
> justincc
> Justin Clark-Casey
> http://justincc.wordpress.com
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>