Hi All, I'm now turning my attention towards 2.7.x series, but before I head off headlong into this I'd like discuss the possibilities for 2.6.x maintenance series, so would like to bring the community and maintenance branch maintainers into a discussion about what we should do next w.r.t the 2.6.x series.
Since getting back from my trip last week I've merged the majority of submissions since 2.6, and also made some further changes myself. These changes include bug and relatively minor feature refinements, the changes which not sweeping, still change the API a little so svn/trunk is no longer binary compatible with the 2.6 branch. Some of the bug fixes change the API, so if we were to keep a strict 2.6.x series binary compatibility then we'd have to skip these changes. One possibility for the 2.6 branch would be to simply embrace all the changes I've made to svn/trunk since the 2.6 release was made, as use this and any other build/bug fixes to go into a 2.6.1. Or the maintenance team could review each of my check-ins over since 2.6 and merge them individually on their own merit. My own plans for the 2.7.x series is the make a 2.7.0 release tomorrow, if we were to import everything since 2.6 we'd need could possible just tag merge everything up to this tag into the 2.6 branch. After 2.7.0 I'll be creating NodeKit directorties like osgVolume, which clearly aren't something that we'll see in the 2.6 branch. The 2.6.x series is a trial of sorts - I'd like to increasingly hand over the reigns of the maintenance of the stable branches to the team that now has write permission on the branches. Those with write permission are welcome to chip in with how they feel the work can be carried out, and how to progress toward making the maintenance releases themselves (including coordinate testing, making of rc candidates, updating of website etc.) I you would like to help out with the maintenance team then please just make this known, so we can look at getting write permission. For each set of branches/releases I'd suggest that we have a lead maintainer that can direct/coordinate the work towards getting the releases out. Thoughts? Over to you ;-) Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
