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

[Paul Melis]

Jean-Sébastien Guay wrote:

> Hi Robert,
>
>> Another aspect to the OpenSceneGraph development cycle is that while
>> quite a few users do track SVN and developer releases not everyone
>> does - many users wait till stable releases come out.
>
>
> Yes, and that coupled with the fact that 2.0 and 2.2 have not had any 
> point releases (x.y.1,2,3...) means that people are generally a bit 
> further behind the SVN curve than they could be. In 2.x that hasn't 
> mattered that much because the API hasn't changed much apart from new 
> features being added (compared to the 1.2 -> 2.0 switch), but it means 
> that people will often have local fixes to the OSG code base that 
> they've been using on top of whichever stable release they were using, 
> while waiting for the next stable release. This makes it a bit harder 
> to make the switch when the stable release eventually comes out...
>
> So I think in addition to all you said in the previous message (and 
> with which I agree), making a few point releases between stable 
> releases would help people keep up to date more easily.

Doing a diff between the 2.4 and current SVN headers it seems the API 
changes that break things are minimal:

* osg::Camera::setIntialDrawCallback -> setInitialDrawCallback
* osg::NodeVisitor::requestNodeFile gained an argument "databaseRequest"
* osg::Texture2DArray::applyTexImage2DArray_subload, some arguments are 
no longer passed by reference
* osgDB::DatabasePager no longer derives from OpenThreads::Thread and 
some methods have changes to parameters. This class seems to have the 
largest amount of changes.
* osgShadow::ParallelSplitShadowMap, forceFrontCullFace() removed
* Small changes to osgTerrain::TerrainTile and friends
* osgUtil::LineSegmentIntersector::setEnd() -> getEnd()

So porting from 2.4 to 2.6 (when it comes out) should be fairly easy, 
unless you do deep stuff with database/terrain paging.

What would be the exact premise for a 2.4 series? Keep the API stable, 
while only providing bug fixes now and then? What about additions, like 
new examples (e.g. osgscreencapture), CMake 2.6 support, threaded HTTP 
fetching of models? Browsing a bit through the SVN log I think the 
number of fixes to backport at this point is relatively minor. But 
backporting for example support for CMake 2.6 might be a bit too much, 
though (haven't looked at it in detail). The amount of maintenance is 
therefore directly linked to what you expect a stable branch to contain 
compared to the development code...

Paul