As you may know, the 2.8.3 release dates from April 5, 2010, almost a year ago.
It lacks a number of things people have wished to see, including the ability to build on VC++2010. Changes for this have been recently posted. The 2.8 branch is held in high regard by a number of organizations who cannot track 2.9 for various reasons. As such, we should probably begin to seriously consider a new 2.8 release to incorporate critical things various people have needed. In private discussion with some of my colleagues, we've talked about the idea of fielding a 2.8.3.1 solely to incorporate the VC++2010 build fixes. This would be binary API and functionality identical to 2.8.3 and would ONLY incorporate changes to the build process necessary to build on VC++2010. Building it on VC++2008 and ALL other platforms should result in binaries identical to 2.8.3, so it's a drop in replacement for 2.8.3. This library would use all the same version numbers as 2.8.3. Discussion on the merits of this are requested. Beyond 2.8.3, we'd like to discuss a possible 2.8.4. Paul Martz, who spearheaded 2.8.3 has write permission to the OSG branch repo and is willing to commit patches made against the branch, but doesn't have bandwidth to actually backport any changes or do any testing. His role in a 2.8.4 release would solely be to tell and guide us on how to follow his process. So if a 2.8.4 release is going to happen, plan to either submit a patch against the branch (as for any OSG change request), or contribute. First, I'd like to open discussion about whether a 2.8.4 release is warranted. Secondly, if you believe it is warranted, what features from trunk do you think are CRITICAL to have in the 2.8 branch? Keep in mind, there's a 3.0 release coming someday. we don't want to turn 2.8 INTO 2.9 or 3.0. There are breaking architectural changes (some minor, some less so) between 2.8 and 2.9, and some organizations won't take a 2.8.4 that has big breaking changes. Thirdly, if there's a feature you want backported, you need to plan to either volunteer to do it yourself, or contribute some funding for someone else to do it. Finally, we'll need people committed to testing the branch to see if it's ready for release. Discuss. -- Chris 'Xenon' Hanson, omo sanza lettere. [email protected] http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. "There is no Truth. There is only Perception. To Perceive is to Exist." - Xen _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
