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 [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
