Hi Robert,
Robert Osfield wrote:
On Mon, Jun 2, 2008 at 2:34 PM, Paul Melis <[EMAIL PROTECTED]> wrote:
Would there be a single stable branch and one development one? I.e. when 2.6
would come out it would supersede 2.4?
Each stable series would be independent. A new stable release such as
2.6.0 would become the main stable branch and it's own series but it
wouldn't replace 2.4.0 and it's own series.
I'd imagine that users might still want to fixes applied to a previous
stable release if that's the version that their app is shipping
against, so a 2.4.1 could come out, then 2.6.0, then another patch to
2.4 would bring it to 2.4.2, then later patch to 2.6.0 would bring its
own series to 2.6.1.
Ok
If I were to tag a 2.4.1 right now I'd just use SVN as I don't have
the time to review all the different changes and back porting them to
2.4.
But that doesn't really solve this on the long term, does it.
This discussion is looking to what we might need to do to solve the long term
maintenance of stable releases, as well as the immediate case of what to do
about 2.4.1. Right now we have no formal system for maintaining stable
releases, as long as we start moving towards some system then I'm happy,
but we have to start moving in this direction even if we just take baby steps.
To be able to
have easily manageable stable branches would mean branching the trunk just
before a new minor stable release and then backporting fixes and small
additions from the trunk to work up to each new point release on the stable
branch.
I'd suggest that a 2.6.x series starts with 2.6.0 and branches this to
make the base for 2.6.1, then this branch gets patches applied to it
from trunk or perhaps separate patches that trunk won't have.
Why not branch to _create_ the 2.6.x series, instead of branching
_after_ 2.6.0? The former is far more commonplace.
It might be that trunk then takes fixes from these branches.
Possibly, but the other way around (merge from trunk -> branch) is the
usual way of doing it. The assumption is that the majority of
development happens on the trunk, and therefore the majority of
interesting stuff to backport is there also. Although it's perfectly
possible to merge back and forth, of course.
For the 2.4.x series we either use the 2.4.0 branch as a base, or 2.5.1 or
trunk. The horse has bolted a bit already on the 2.4 series
as we are already into the 2.5.x developer series so it's a bit of
unusual situation - the proposed system of stable developer series
maintenance is rather late coming.
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.
Paul
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
