[osg-users] OpenSceneGraph 2.4.1 stable release?? If/when/when/who

[Eric Sokolowsky]

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 <paul at science.uva.nl> 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 at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>