[GRASS5] What's holding 5.3.0 release?

[Paul Kelly]

On Fri, 30 Jan 2004, Markus Neteler wrote:

> ... the subject says all:
>
> What's holding the 5.3.0 release?
>
> The last month I received several comments telling that the current
> situation of GRASS development for new programmers is confusing.
> They see "5.0.3 stable" while most recommendations are "please use
> 5.3, it's much better and more widely tested".
>
> In my opinion a 5.3.0 release is urgently needed.
> And it should not be called "unstable" according to the
> odd minor release number as it would be too discouraging to
> stimulate new development.

Those two paragraphs may be a question for Bernhard as I recall he
promoted this separate stable / unstable branch arrangement. I posted my
thoughts on it before:
http://grass.itc.it/pipermail/grass5/2003-January/007012.html and also
agree with Markus' comments above except that 5.3 should still be called
unstable. Well not stable anyway. Maybe 'semi-stable'?

I will try and answer the first question: Off the top of my head here are
some things that should be fixed:

1) Remove gdalbridge code from r.in.gdal

2) Update internal GRASS PROJ library to remotesensing.org proj apart from
the local bugfixes (in this case disable the --with-proj option so we have
to use the internal fixed version) *and/or* change modules that convert
projected co-ordinates to lat/long to use pj_latlong_from_proj() function
(to workaround PROJ bug number 368
http://bugzilla.remotesensing.org/show_bug.cgi?id=368 )

3) Fix up glX dependencies in NVIZ (really I'm not too sure about the
status of this; probably good to release and let the bug reports flow in)

4) Fix conditional compilation of g3d modules for glX dependencies and
other variable OpenGL stuff

5) Various updates for v.in.dxf and v.in.dxf3d: an option to write to
category labels to dig_cats instead of dig_atts. Also some fixes people
have sent in should be merged (e.g. I remember something 8-bit character
encoding)

6) r.terraflow should only be compiled if g++ is detected; it won't work
with any other C++ compiler

7) Make --enable-gmake=no the default and use the alternate build
mechanism for shared libraries---this needs a few changes for Cygwin.
Maybe dig2 and vect libraries merged into one big library? Or else
compiled as static library. Also driverlib compiled statically.

But yes of course we can release now and put off these fixes until 5.3.1.
And I can probably do the release though it would take me a while. I would
need some instructions on how to sign the source code tarball (and
possibly the binaries).

Paul