MarkusN wrote:
> The student will gain from switching also in terms of the
> other many improvements:
>
> http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures
fwiw, & others may disagree, but IMO development code should never
be used for "final runs", and while testers are most welcome,
they should be prepared and able to dig themselves out of unknown
trouble.
I can cite times in the past where the dev code silently produced
bad data for some months before a bug was caught (saved me a
month+ of reprocessing time by using the stable version for the
"production" runs), others in the dev code where `rm -rf "$TMP"*`
deleted all files in someone's home dir when g.tempfile failed
on Mac without a check around it, and the general time sink of
chasing a moving target.
In addition, if the student will want to publish anything, it
would look a lot better to the reviewers w.r.t. reproducible
results if an official version is cited in the methods section.
in the case of the r.walk option it is not new at all; I'm just
speaking generally, and with an abundance of caution. Porting
raster C code between G6 and G7 takes a bit of work, but
typically it's just changing a few function names. As Markus
notes this one is a bit too complicated for official backport
consideration, but people can do what they like at home.
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
