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.
For the latter you can easily use an SVN tag, but I'm sure you knew that.
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.
Right, but that is for maintenance of the next stable branch. How about
the current one (2.4)?
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.
At this point I'd suggest to create the 2.4 branch and allow some people
to backport stuff from the trunk as a first step. When we get to a point
where a 2.4.1 release is viable we can look at the infrastructure needed
in terms of scripts. This first release might even be done by hand to
get to know what is needed and what can be automated.
For the actual merging from trunk to the stable branch I suggest we take
a good look at svnmerge (http://www.orcaware.com/svn/wiki/Svnmerge.py).
This is a script that assists in the merging process, preventing the
same things to become merged twice among other things. It also keeps a
list of revisions already merged for a branch and has an option to block
certain revisions from being merged. The other nice thing is that it
copies the log messages of revisions being merged, so it's easy to track
what a merged revision actually contained (assuming the original log
message was descriptive). The Python folks use it extensively and seem
to be happy with it. Here's an example log message from the branch being
merged _into_, note the two revisions coming in:
r63798 | benjamin.peterson | 2008-05-29 23:22:40 +0200 (Thu, 29 May
2008) | 17 lines
Merged revisions 63460,63464 via svnmerge from
svn+ssh://[EMAIL PROTECTED]/python/trunk
........
r63460 | ronald.oussoren | 2008-05-18 15:54:47 -0500 (Sun, 18 May
2008) | 6 lines
- Add unittests for platform.mac_ver (or rather, ensure that the
unittest for
that function actually tests something on OSX).
- Add documentation to platform.mac_ver that explains why the middle
element
of the return value will not contain useful information.
........
r63464 | benjamin.peterson | 2008-05-18 17:07:42 -0500 (Sun, 18 May
2008) | 2 lines
fix test_platform (os was not imported)
........
I must admit that I haven't used it at all, but it seems like a useful
tool to do this sort of work. I especially like the automatic
documentation of what was merged. One last thing to mention is that the
script _never_ commits anything by itself, that is still the
responsibility of the user, who can still revert any things done by the
script.
If we go the route of using svnmerge then it makes sense to first do
some tests using a scratch branch.
Paul
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
