Hi Paul, On Mon, Jun 2, 2008 at 1:23 PM, Paul Melis <[EMAIL PROTECTED]> wrote: > Doing a diff between the 2.4 and current SVN headers it seems the API > changes that break things are minimal: >... > 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.
Indeed, even these API changes are unlikely to affect the majority of users. In fact the 2.0 to 2.2 to 2.4 to the eventual 2.6 are all likely to be relatively painless ports. > What would be the exact premise for a 2.4 series? Keep the API stable, while > only providing bug fixes now and then? This would be the rough plan - to keep a stable API, and if possible binary compatible too where possible, and just make stable releases when particular fixes are really needed, it might be that the maintainer will just declare some fixes as ones that will be dealt with by the next major point stable release. New features I would not expect to be something to roll into stable release series, it might be occasional that a bug fix comes with a new feature or change in a feature in which case the maintainer will just have to show some discretion. The aim should be to help users that require stable releases, wishing to avoid the need for open ended porting to new versions - at most an upgrade to a stable minor point release should be a recompile of the OSG and their app, this is something that needs to be done consistently so users needn't worry about extra porting work coming about due to these extra releases. > 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... It's support for CMake 2.6 which is one of the motivations for make a 2.4.1, as well as the bug fixes. In terms of making a 2.4.1, we could either use SVN trunk as the source and not bother back porting, or do the job by back porting to 2.4. Just taking SVN would be quicker and less initial work, but it'd introduce new features into the bag that haven't been tested thoroughly yet, but then there is always 2.4.2 to fix all the problems in 2.4.1 ;-) If I were to tag a 2.4.1 right now I'd just use SVN as I don't have the time to review all the different changes and back porting them to 2.4. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
