[GRASS5] GRASS development roadmap proposal

[H Bowman]

Others wrote:
> Markus
>> Glynn
>>> Bernhard
>>>> Paul


> Here a proposal which tries to minimize the version
> naming problems

I think it's a very good forward looking plan. Especially as small 5.0.2
bug fixes for things like NVIZ are getting mixed in with major code
changes ..
It helps to aviod the current situation happening all over again as
well.


> -----------------------+------------------------
> 5.8.0                     5.9.0
> - bugfixes for 5.7.0      - eliminate sites [2]
>                           - improve raster format
>                           - improve image processing
> -----------------------+------------------------

To that list for 5.9.0 I'd like to add a wish for a redesigned $MAPSET/*
directory structure (giving another reason for 6.0 to follow 5.9).


>>> 	It all only makes sense if the 5.3.x cycle is 
>>> 	compartively very short.
>> In that case, it might be better to skip the 5.3.x naming, and just
>> use 5.4.0-pre1, -pre2 etc.

5.3 might exist for the ripping out of old PROJ code etc from CVS HEAD,
but as soon as it builds properly it might become 5.4.0-pre1. As long as
no (other) new major updates are allowed to be added to this branch, I
think CVS HEAD is probably very close to 5.4.0 right now.
With 5.0.x stable the early 5.4.0preX releases can be quicker and do not
have to be perfect.
Does having a 5.3+/5.0 split speed up the process of tagging for a new
release for Glynn & Markus?

An immediate feature freeze on significant changes to 5.3 also keeps
5.1/5.7 as the current experimental branch and avoids possible
stagnation on it and Radim frustration..


>>>> we might as well go ahead and remove the internal copy of PROJ that
>>>> is in GRASS and make an external PROJ installation an absolute
>>>> requirement. 
> For me it sounds good. There is no much point in maintaining a
> partially outdated PROJ4 in a 5.3/5.4 release.
> One thing we should have in mind is if Debian/SuSe/Mandrake/Redhat/...
> have a RPM package and, if not, if we could suggest to add it.

Debian 'testing' has PROJ 4.4.7 as the 'proj' package already. No
problem on making it a dependency there as any new debian GRASS binary
would end up in 'testing' as well.
(http://packages.debian.org/proj)

There isn't a Debian GDAL package, but there are shapelib and libshp1
packages which are based on GDAL, for what that's worth.


> Well, I don't expect any 5.3.x release the next days :-)
> But maybe a 5.0.3, to stop the repeated NVIZ/tcl84 etc questions.

In general I think it would be a good idea to have preliminary releases
announced on the developer's list a week before the proper announcement
on the webpage/grasslist so we have more of a chance of catching future
gotchas like that one.


In any effect I think a firm feature freeze on the 5.0.x CVS branch (now)
would be a very good idea and adding datum transforms as a separate
add-on upgrade to 5.0.x would cause more confusion than good.
Backporting minor bug fixes to 5.0.x until 5.4 is mature shouldn't be
too much extra work.



Hamish