HI Paul, On Wed, Oct 21, 2009 at 6:21 PM, Paul Martz <[email protected]> wrote: > We'll want this capability in svn trunk, but waiting for a new stable > release, and all the associated testing, is impractical for my client. So we > need another venue for release. > > Branching from 2.8.2 is a good suggestion, thanks. We can do this as either > a 2.8.2 branch, or a 2.8.3 point release. > > To do this as a 2.8.3 point release, I agree we should keep binary > compatibility. I could implement this change as a CPP macro controlled > through CMake without affecting binary compatibility. The default behavior > would be the current behavior, but developers could change this behavior in > CMake so that the resolve blit doesn't resolve the depth buffer. It would be > "all on" or "all off", but I think this will be sufficient for my purposes. > > I'll discuss with the client and see if they prefer a non-ABI compatible > 2.8.2 branch, or a 2.8.3 with CMake controlled MSFBO resolve behavior.
I don't see much point in having a 2.8.3 that is identical to 2.8.2 save for changes that are only enabled by a CMake change. This is a special release for a specific feature for a specific client, I would branch and name the branch according to the nature of your changes rather than try to try to disguise it as a conventional point release. I there were other bug fixes to go into the OSG-2.8 branch then I believe we'd have good justification for a 2.8.3 release, even then I'm not sure that the changes that you are considering would be appropriate to be rolled into it. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
