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

Stefan Andersson stefan at tribalmedia.se
Mon Dec 15 08:52:57 UTC 2008


> > I can see some people being hesitant to commit to supporting this> > because they don't want to worry about committing to two branches each> > time they have a fix, or they don't want to maintain two slightly> > different code bases.
 
This would be 100% optional, and probably done by a small group of devotees (like me and Darren, as in the case of the last stable) whose only humbly wish is to get a heads-up from peple whenever a good, clean bug fix has been committed.
 
> > Bug reports could also become more of a hassle as> > some users will report bugs against the trunk, while others against the> > stable branch.
My concept will not work if we don't re-branch new stables reasonably often - the heart of the concept is that 'stable' should not deviate from trunk very far at all, just minor bug fixes and changes deemed 'harmless'.
 
The reason, of course, is exactly that we should be reasonably certain a bug exists in both branches.
 
Apart from that, we have that same problem on every revision. The user needs to tell us what revision (or trunk) the error is on.
> > Having said that, I can see a benefit for having a stable branch.> > Ideally it would follow trunk pretty closely, and when it becomes> > challenging to apply patches to both trees without too much massaging,> > it's time to do final stabilization on that final branch and release.
That was the general idea. Bu tI would say, given the agile nature of the project, that we just _define_ that, "when bug fixes does not apply cleanly, it's an indication we should bump the number".
> > I would like to encourage you to give this a try.
 
We already are. At the moment, I'm just waiting for people to tell me we have a reasonably stable revision that I can branch again.
 
> > In the meantime, don't expect too much> > commitment from all the devs, and be prepared to take responsibility> > for this stable branch. After some time, we can all look back at how> > things went and decide what to do in the future.
This is basically what happened with 0.6.0-stable. Only thing we need is help with finding the revisions, and to get tipped about good stabilizing fixes in trunk.
> The problem with stable branches... is they aren't. If you add code to> a branch, you have the potential to break it, especially on a source> base as complex as OpenSim.
True as that may be, of course it depends on what type of code you add, and how much.
 
If we were talking doing serious work on a 'real' branch, I would be much more inclined to agree, but the point of this is to keep it ligth, agile and to a minimum of deviation.
> Personally, I'm going to stay focused on trunk, that's where my time and> interest lies.
 
Then do. I'm not trying to rally resources devoted into this, I'm merely trying to work out a process that would work given the nature of the OpenSim project.
 


More information about the Opensim-dev mailing list