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

[Paul Melis]

Robert Osfield wrote:

>Hi Paul,
>
>On Mon, Jun 2, 2008 at 4:03 PM, Paul Melis <paul at science.uva.nl> wrote:
>  
>
>>Why not branch to _create_ the 2.6.x series, instead of branching _after_
>>2.6.0? The former is far more commonplace.
>>    
>>
>
>The system since the 1.9.x dev series has been that we tag when ready
>to officially make a release, with the 1.9.x series converging towards
>a point when 2.0.0, using the last few dev releases as release
>candidates, and finally the trunk was in good enough state to have
>2.0.0 tagged from SVN trunk.
>
>The other approach, which you suggest, is rather than use the dev
>releases as release candidates, branch a stable release when we get to
>a feature freeze period and then make release candidates based on this
>branch.  The final official release would then bee a branch + a
>revision number than holds the particular release in a point in time.
>  
>
For the latter you can easily use an SVN tag, but I'm sure you knew that.

>When moving to having maintainence releases of a stable series using
>dev series as pre releases doesn't work, as the dev series already
>heads off in towards then next major stable point release.  So... now
>we a proposing the stable maintaince releases then we need to move to
>a new system - branch first then stabilising this code base in
>readiness for a 2.4.1, 2.4.2 seems like the way to go from here on
>out.
>
>For 2.6.0, it'd suggest we use SVN trunk/later 2.5.x dev series as pre
>releases of 2.6.0 get things tested enough to know we are roughly in
>the right ball park functionality/quality wise, then copy trunk across
>to a 2.6.0 branch and then use this as the base of release candidate
>series before the final 2.6.0.   Once the 2.6.0 branch happens the
>stable release maintainer would then become actively involved in
>shepherding the code base to its eventual official release.
>  
>
Right, but that is for maintenance of the next stable branch. How about 
the current one (2.4)?

>  
>
>>As the differences between 2.4 and SVN are still small now is the time to
>>start the process...
>>I'm willing to help to backport fixes and other things from trunk to the 2.4
>>branch. I can't tell you at this moment if this would be a long-term
>>commitment, though.
>>    
>>
>
>I think it'd be hard for anyone to sign up long term to something,
>taking short term responsibility won't be a problem as long as we all
>follow a set of systems that are published and adhered too/use the
>same scripts/tools - so others can easily drop in to help out when
>others move on/are away on holiday.
>
>Right now we don't have all the systems published/scripts etc, so it'd
>be a case of documenting as we go along.  First step is to find a set
>of volunteers who are willing to going along this journey, get them
>write access to making branches of the OSG.  It might even be worth
>having a scratch pad set of branches that we can new maintainers can
>experiment with.
>  
>
>I'm open to suggestions.
>  
>
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.

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:

r63798 | benjamin.peterson | 2008-05-29 23:22:40 +0200 (Thu, 29 May 
2008) | 17 lines

Merged revisions 63460,63464 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk

........
  r63460 | ronald.oussoren | 2008-05-18 15:54:47 -0500 (Sun, 18 May 
2008) | 6 lines

  - Add unittests for platform.mac_ver (or rather, ensure that the 
unittest for
    that function actually tests something on OSX).

  - Add documentation to platform.mac_ver that explains why the middle 
element
    of the return value will not contain useful information.
........
  r63464 | benjamin.peterson | 2008-05-18 17:07:42 -0500 (Sun, 18 May 
2008) | 2 lines

  fix test_platform (os was not imported)
........

I must admit that I haven't used it at all, but it seems like a useful 
tool to do this sort of work. I especially like the automatic 
documentation of what was merged. One last thing to mention is that the 
script _never_ commits anything by itself, that is still the 
responsibility of the user, who can still revert any things done by the 
script.

If we go the route of using svnmerge then it makes sense to first do 
some tests using a scratch branch.

Paul