Hi Paul el. al, On Thu, Oct 22, 2009 at 5:13 PM, Paul Martz <pma...@skew-matrix.com> wrote: > If I'm not mistaken, we can branch the trunk either right now, or just prior > to the start of Robert's GL ES2 work, and Chris could add his changes to the > branch, and that branch could eventually lead to a 2.10 stable release. > Robert's trunk work could eventually lead to a 2.12 release. The downside of > this is there might be a potentially nasty merge in there somewhere. > > Robert, Chris: Thoughts?
Just for clarification, I'm not a significant way through the OpenGL ES 2.0 port, and all my changes have been done against svn/trunk, and save for a few more changes that I made yesterday afternoon all my work is already in svn/trunk. Originally I was planning to make a branch of the OSG to do the OpenGL ES 2.0 port, then merge back in the changes, but as I got into port I found ways of minimizing the code differences between the various targets, and managing the differences in ways that well encapsulated - the upshot of this was I have been able to undertake the port with far less intrusive changes to the API and the implementation. In fact the public API itself is hardly changing at all and we may even be able to have an ABI compatible OSG across the range of OpenGL targets. If my current progress on the port keeps up we could well see the bulk of the port done and checked in by the end of this month. The door will be opened to supporting OpenGL ES 1.x, and OpenGL 3.x with relative ease, and see no reason why both of these wouldn't achievable in November and be rolled into a stable release before Christmas. To do the OpenGL ES 1.x and OpenGL 3.x ports I'll need assistance from the community, but once I've got the framework for supporting multiple OpenGL targets in the OSG it should far easier for others to dive in and help out. During next month I also plan to catch up with submissions get the OSG svn/trunk in a shape primed for a stable release. Should this stable release be 2.10, or... 3.0, we'll if we get OpenGL ES 1.x, 2.0 and OpenGL 3.x support working then I am beginning to think that it's a big enough step forward to call it OpenSceneGraph-3.0. Curiously the API for the next release will actually be pretty close to that of 2.8, and the rest of the 2.x series for that fact, so porting to 3.0 would probably be easier than that of OSG-1.x to OSG-2.x. Such an decision on a 3.0 would mean that we'd leave out the major API refinements for doing shader composition etc. for later rev's of the OSG, but perhaps even these might be doable without major changes to the public API, as the OSG API has already turned out to be far more resilient to accommodating new functionality than I had ever expected. I guess evolution rather than revolution for software development is often the most practical and productive way forward. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
