[osg-users] OpenSceneGraph 2.4.1 stable release?? If/when/when/who

Tue Jun 3 07:04:56 PDT 2008

Robert Osfield wrote:

>Hi Paul,
>
>It sounds like we are now on roughly the same wavelength w.r.t how to progress.
>
>  
>
>>Right, but that is for maintenance of the next stable branch. How about the
>>current one (2.4)?
>>    
>>
>
>I'd suggest going with a branch from 2.4.0 or 2.5.1 (if you want to be
>lazy)  i,e
>
>svn copy http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.4.0
>               http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.4.x
>
>Or name the branch OpenSceneGraph-2.4, or OpenSceneGraph-2.4.series.
>I'm open to suggestions on naming of a branch - whatever makes sense
>to those browsing the branches.
>  
>
I'd suggest OpenSceneGraph-2.4. As it is located under /branches, that 
should be clear enough.

>Or perhaps we should start with an OpenSceneGraph-test branch.
>
>  
>
>>At this point I'd suggest to create the 2.4 branch and allow some people to
>>backport stuff from the trunk as a first step. When we get to a point where
>>a 2.4.1 release is viable we can look at the infrastructure needed in terms
>>of scripts. This first release might even be done by hand to get to know
>>what is needed and what can be automated.
>>    
>>
>
>I can post my simple scripts on the wiki, scripts are good as once you
>have one that works reliably you can make releases without worrying
>about making typo's at a crucial moment.
>  
>
I assume these are shell scripts? Should we decide in advance that the 
release scripts are targeted at a Linux/Unix system?
Should we support two sets (one for Linux, one for Windows) to support 
maintainers on Windows?

>>For the actual merging from trunk to the stable branch I suggest we take a
>>good look at svnmerge (http://www.orcaware.com/svn/wiki/Svnmerge.py). This
>>is a script that assists in the merging process, preventing the same things
>>to become merged twice among other things. It also keeps a list of revisions
>>already merged for a branch and has an option to block certain revisions
>>from being merged. The other nice thing is that it copies the log messages
>>of revisions being merged, so it's easy to track what a merged revision
>>actually contained (assuming the original log message was descriptive). The
>>Python folks use it extensively and seem to be happy with it. Here's an
>>example log message from the branch being merged _into_, note the two
>>revisions coming in:
>>    
>>
>
>I'll leave it up to you guys to work out what tools.
>
>Another thing that might be useful is watching svn check-ins, as well
>as convansing users requests for particular fixes to be merged.
>  
>
Do you mean the RSS feed? Or is there a separate mailing list?

One thing about the feed that bugs me is that the messages don't contain 
newlines (the <body> tag contains a single <pre> tag containing the log 
message without newlines). Is this something that can be fixed? They're 
really hard to read in the current state.

>I can easily make the branch once we decide upon an name, then we'll
>need Jose Luis Hidalgo to add logins and write permissions for
>yourself, Eric and any others who wish to work on maintaining 2.4.x.
>  
>
One thing about subversion is that it's relatively easy to set up a 
local file-based repository containing some representative files to 
experiment with. Perhaps we don't need a test branch, but on the other 
hand testing on the actual infrastructure is probably a good idea.

Paul