Not really sure how to coordinate the maintenance other than postings in the osg-submissions thread whenever a maintainer decides to fold a submission into the 2.6.x branch.
I'm flexible on breaking binary compatibility; anything that fixes a bug should be considered for inclusion into the branch. A more interesting question is how to decide what is a bug fix (to be included on the branch) and what is a new feature (that should not go on the branch). In most cases it's easy to say, buy there are some grey areas. I suggest we handle such issues on a case by case basis. -Paul > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Robert Osfield > Sent: Sunday, August 17, 2008 10:37 AM > To: OpenSceneGraph Users > Subject: [osg-users] Steps towards OpenSceneGraph-2.6.1 > maintenance release > > 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 > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce > negraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
