Hi Eric, Thanks for the offer of help.
Having a hard a fast rule w.r.t binary compatibility will preclude some important bug fixes, this has happened with previous releases, and includes fixes to 2.4.0. So I'd suggest that one uses discretion about what parts get merged and if it means breaking compatibility so be it, one can bump the SO version number, even if it means skipping a few to be newer than the last developer release - we just have to coordinate between ourselves. Robert. On Mon, Jun 2, 2008 at 10:47 PM, Eric Sokolowsky <[EMAIL PROTECTED]> wrote: > I'm willing to help port bug fixes back to stable branches. I have an > ulterior motive though; I made a particular change in the Inventor plugin > that is now in SVN that I would like to see in a stable release. I think > that only bug fixes should be ported back; API changes would have to wait > for a developer release or a new stable release. This would prevent SO > version conflicts between release and developer versions. > > -Eric > > > Robert Osfield wrote: >> >> Hi Paul, >> >> On Mon, Jun 2, 2008 at 4:03 PM, Paul Melis <[EMAIL PROTECTED]> wrote: >>> >>> Why not branch to _create_ the 2.6.x series, instead of branching _after_ >>> 2.6.0? The former is far more commonplace. >> >> The system since the 1.9.x dev series has been that we tag when ready >> to officially make a release, with the 1.9.x series converging towards >> a point when 2.0.0, using the last few dev releases as release >> candidates, and finally the trunk was in good enough state to have >> 2.0.0 tagged from SVN trunk. >> >> The other approach, which you suggest, is rather than use the dev >> releases as release candidates, branch a stable release when we get to >> a feature freeze period and then make release candidates based on this >> branch. The final official release would then bee a branch + a >> revision number than holds the particular release in a point in time. >> >> When moving to having maintainence releases of a stable series using >> dev series as pre releases doesn't work, as the dev series already >> heads off in towards then next major stable point release. So... now >> we a proposing the stable maintaince releases then we need to move to >> a new system - branch first then stabilising this code base in >> readiness for a 2.4.1, 2.4.2 seems like the way to go from here on >> out. >> >> For 2.6.0, it'd suggest we use SVN trunk/later 2.5.x dev series as pre >> releases of 2.6.0 get things tested enough to know we are roughly in >> the right ball park functionality/quality wise, then copy trunk across >> to a 2.6.0 branch and then use this as the base of release candidate >> series before the final 2.6.0. Once the 2.6.0 branch happens the >> stable release maintainer would then become actively involved in >> shepherding the code base to its eventual official release. >> >>> As the differences between 2.4 and SVN are still small now is the time to >>> start the process... >>> I'm willing to help to backport fixes and other things from trunk to the >>> 2.4 >>> branch. I can't tell you at this moment if this would be a long-term >>> commitment, though. >> >> I think it'd be hard for anyone to sign up long term to something, >> taking short term responsibility won't be a problem as long as we all >> follow a set of systems that are published and adhered too/use the >> same scripts/tools - so others can easily drop in to help out when >> others move on/are away on holiday. >> >> Right now we don't have all the systems published/scripts etc, so it'd >> be a case of documenting as we go along. First step is to find a set >> of volunteers who are willing to going along this journey, get them >> write access to making branches of the OSG. It might even be worth >> having a scratch pad set of branches that we can new maintainers can >> experiment with. >> >> I'm open to suggestions. >> >> Robert. >> _______________________________________________ >> 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 > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
