Markus Metz wrote: > IMHO, it would make maintenance much easier if one of 6.4 and > 6.5 would go rather sooner than later.
I absolutely and quite strongly disagree. It is invaluable to have a staging area to test backports before putting them into the stable branch, and trunk has diverged too far from 6.4 to allow that to take the role. We have experimental/trunk, limited testing for the stable branch, and the final branch. Lately we've been pretty good about not developing new code in devbr65, meaning clearer ideas about what should be really backported into the 6.4 stable branch since there is less noise. We must -at all times- be ready to tag a new release from the 6.4 stable branch on very short notice. Partly in case a severe data bug is found, but more critically if a license problem turns up. If you get rid of your staging area it's impossible to guarantee that the release branch will be at release quality while bug fixes are being worked out and tested. It also gives a chance for things which don't quite rise to the level of "critical bugfix" to be left unshared. It's a *good* thing that we can look through trac and pick and choose what to actually put into 6.4.3. if it helps: To keep the merging burden low, I use a couple of tiny scripts to make the merge command a trivial one liner. with the ending of new development in 6.5svn this becomes even simpler. svn65merge: run from trunk/ or relbr64/ dirs with rev # as $ svn65merge 12345 #!/bin/sh if [ $# -eq 1 ] ; then svn merge -c $1 https://svn.osgeo.org/grass/grass/branches/develbranch_6 else echo "usage: cd grass7; svn65merge rev_number" fi ##### svn64merge: same, for pulling from relbr64 into devbr6: #!/bin/sh if [ $# -eq 1 ] ; then svn merge -c $1 https://svn.osgeo.org/grass/grass/branches/releasebranch_6_4 else echo "usage: cd grass65; svn64merge rev_number" fi ##### and finally svn7merge: for pulling from trunk into devbr6: #!/bin/sh if [ $# -eq 1 ] ; then svn merge -c $1 https://svn.osgeo.org/grass/grass/trunk else echo "usage: cd grass65; svn7merge rev_number" fi ##### best, Hamish (sorry I haven't been able to help much with the latest push, I'm juggling 4 other deadlines right now; I'll jump in as soon as I can) _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
