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