[GRASS-dev] GRASS 6.3.0

[Helena Mitasova]

Well given all the troubles reported recently we may as well need RC6  
unless you and Markus  have a good sense that these troubles are only  
in the svn version and not backported to the release.

I would love to get GRASS6.3 out soon - people are still downloading  
6.2 as the stable GRASS and GRASS6.3 is just so much better. And I  
need to get some stable, official release installed in some labs and  
don't want to use 6.2

thanks a lot, Helena


On Mar 17, 2008, at 6:54 PM, Martin Landa wrote:

> 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 *
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev