HI Michael, On 15 June 2013 15:59, michael kapelko <korn...@gmail.com> wrote: > I'm not sure I follow the discussion, since each post is starting to become > a separate article, but I'll try to tell what I think.
The thread might be a little meandering, but it's still roughly on topic. The meandering is partly down to be testing out different API and implementation approaches. > I don't know the policy on OSG ABI, but if it's to keep ABI compatible > between some releases, I would: > * add compile flag to select between old and new Geometry (defaults to old > one); > * warn during compile time and during running (into the log) that using the > old Geometry is deprecated and will be removed in the following stable > release; > * warn in changelog about the coming ABI breakage; > > If the policy is only to keep API compatibility with some minor changes like > obsoleting unused functions, then Geometry could be removed. The approach we've taken has been for patch releases within a stable release set to remain binary compatible, i.e. 3.0.0 is binary compatible with 3.0.1. For developer series I don't attempt to retain binary compatible, and don't expect to retain binary compatibility. In general I do try and maintain the bulk of the API so the majority of OSG users can move between developer and close stable releases without too much effort. My current expectation is that the new cleaned up, fast path only osg::Geometry will not have all the methods and data structures that OSG-3.0.x osg::Geometry had but for most users will just compile and work as before. Those using slow path API's such as array indices and BIND_PER_PRIMITIVE will have to do something extra, either porting away from these long deprecated features, or adding a call to like geometry->fixDeprecatedData(); I don't know yet whether we should make these deprecated API's #ifdef'd out or not yet, if we do we'd want to maintain the ABI so use of inline functions may be the way to go. I'm getting close to checking in my new cleaned up osg::Geometry, once I do hopefully most users will be able to say of that nice cleanup and all I had to do is recompile, but with others using the old deprecated functionality we'll need to help them port across/refine what the OSG provides in terms of fallback. Once I have the cleanup version of osg::Geometry checked in there will still be work within the OSG to continue moving across to using just the non deprecated API, for this I'll need assistance from the community. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
