[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 1:23 PM, Paul Melis <paul at science.uva.nl> 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.
>  
>
Would there be a single stable branch and one development one? I.e. when 
2.6 would come out it would supersede 2.4?

>>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 ;-)
>  
>
Hmmm, that kind of defeats the purpose of making a 2.4.1 release, if 
it's actually just 2.5.1 with a different number, as that _would_ 
include (minor) API changes.

>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.
>  
>
But that doesn't really solve this on the long term, does it. To be able 
to have easily manageable stable branches would mean branching the trunk 
just before a new minor stable release and then backporting fixes and 
small additions from the trunk to work up to each new point release on 
the stable branch.

Paul