[GRASS-dev] GRASS 6.3.0

[Martin Landa]

Hi,

2008/3/15, Hamish <hamish_b at yahoo.com>:
> 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 *