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
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to