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