Hi Chris, I'm all for an 2.8.4 release. It will require other members of the community to manage the reelase though as I'm absolutely maxed out at present. There has been lots of discussion over the last couple of years about having the community take a more active role in stable release maintenaince, and there is a number of members of the community that have write access to the branches portion of the website, I'm afraid I can't recall all of them off the top of my head - Paul Martz is obviously one of them ;-)
If you or others wish to take the reigns on making a 2.8.4 release then I'd welcome this, and we can't get server admin, Jose Luis Hidalgo, to add the required permissions. The next step would be to merge any submissions that are specific to the 2.8 branch. Robert. On Wed, Mar 16, 2011 at 5:13 PM, Chris 'Xenon' Hanson <xe...@alphapixel.com> wrote: > 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. xe...@alphapixel.com > 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 > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
