Hi, 2008/3/15, Hamish <[EMAIL PROTECTED]>: > Martin Landa wrote: > > we are a little bit late with releasing 6.3.0, Hamish: > no big hurry.
well, just comparing rc5-rc1 --- almost 5 months (to be honest, postponed mainly because wxGUI backport). Anyway I would personally prefer *smaller* release intervals (more releases in the result). Just to illustrate 6.0.0 20050310 ~ 1y5m 6.1.0 20060811 ~ 2m 6.2.0 20061031 ~ 1y5m 6.3.0 2008???? 6.4.0 2008? 7.0.0 ? (development not started) > > looking at [1,2] I don't see any (really) blocker issue (maybe vdigit > > linking problem, but this can wait for 6.3.1 I guess). Hamish: > Before 6.3.0 I would like to finish making r.tileset "echo -n" portable > (trac bug #81) and then backport r.in.wms fixes, and also see if we can > fix the GIS.m off-by-one fill/boundary rendering (trac bug #72) > > http://trac.osgeo.org/grass/ticket/81 > http://trac.osgeo.org/grass/ticket/72 > > > As r.in.wms has been reported to work on Mac 10.5, I infer that the > #!/bin/bash used by r.tileset makes it use bash's internal echo (which > supports echo -n) instead of a system BSD /bin/echo which does not. (??) > Even if that is so, it's probably a good idea to fix anyway. The eval > within a function within another function and array quoting makes my head > hurt, so for clarity's sake I am leaning towards going with Paul's > suggestion of using GRASS's own $GISBASE/etc/echo there and keeping the > -n, versus Glynn's patch which I find hard to review beyond trial & error > tests which I can't properly do without OSX 10.5, which I don't have. > > Not having to resort to using our own echo.c is preferable, but for the > pending 6.3.0 release this seems to me the less worrisome solution. OK, I cannot judge it, anyway could be maybe fixed for 6.3.1 or 6.4.0. > There are a lot of other script fixes not backported to 6.3.0, mostly > bulk quoting of variables. I didn't backport them as I have not > individually tested the changes and so don't guarantee they are no > introduced typos. These will help with the spaces in pathnames problems, > which are mostly a MS Windows phenomenon. I did not systematically quote > everything, so it is almost certain that there will be more unquoted path > and file names. These fixes might be nice to get out to MS Windows users > in a 6.3.1 after more testing in SVN/trunk. Probably easier to cut a new > 6_3_1 branch from the main grass6 line than to bother backporting things > to 6.3.0's branch. Hm, creating branch for 6.3.1 seems to be a bit complicated to me. I would prefer releasing 6.3.0, creating branch for 6_4 (trunk for 7.x). Releasebranch_6_3 used for 6.3.1 (after tagging 6.3.0) as usually. > (unless a major bug is discovered and we want to release a quick 6.3.1) > > > Is there a need for one last 6.3.0rc6 before release since all the new wx > backport changes? Maybe yes. I don't know maybe this kind of decisions should be done through PSC or at least by release manager. Martin -- Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa * _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
