Hi Andy,

On Thu, Feb 19, 2009 at 4:47 PM, Andy Skinner
<[email protected]> wrote:
> Turns out we are using that (though we are really in need of getting out of 
> using SceneView, and maybe we won't need it anymore).
>
> Any idea if there will be a 2.8.1, with various things fixed since?

That all depends on how things progress with 2.8.0 and the demand for
2.8.1 from the community.  Given there are problems appearing after
the 2.8.0 due to lack of breadth of testing then I'd suggest waiting
for a few more weeks for more testing to be done to catch remaining
issues.

In the run up to 2.8.0 I called, and called, and called for testing
with 3rd party applications.  But still not enough testing occurs.
I'm afraid there isn't much more I could have done, too many users
wait till after a stable release is tagged before they try out
testing.

> This is the only one that has caught my eye.  We can bring it in, but would 
> like to be at a released version.
>
> We were able to test compiling 2.8 as it was getting ready, but not run it 
> with our software.  We may have seen this if we'd had time to do that.  Do we 
> know when the problem went into the code?

The changes in reset() will have been part of a memory leak fix that I
checked in at the end of January:

r9549 | robert | 2009-01-26 15:16:24 +0000 (Mon, 26 Jan 2009) | 5 lines

Fixed effective leak in Program::PerContextProgram caused by
previously osg::State keeping a set of
std::ref_ptr<Program::PerContextProgram> without ever pruning t
his list.
The fix was to convert the osg::State to use C pointers for the set of
applied PerContexProgram objects, and use the osg::Oberver mechanism
to avoid dangling point
ers for being maintained in osg::State.

So it's a case of one step forward, one step backward... fix one bug,
introduce another ;-|

Catching regressions like this are made harder be the wide range of
usage models that users put the OSG through.  Catching problems in
common usage models is easier, the less used pathways requires the
wider breadth of user testing.

Robert.
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org

Reply via email to