[GRASS5] proj changes for releasebranch?

[Markus Neteler]

On Thu, Jul 03, 2003 at 04:36:15PM +0100, Glynn Clements wrote:
> 
> Paul Kelly wrote:
> 
> > > To prepare the previous releases, I've run diff.sh, then posted a
> > > summary of the changes in order to obtain opinions as to which changes
> > > should be merged and which shouldn't.
> > 
> > I thought maybe if I committed the things I am happy with to the release
> > branch now, then the amount of other changes would be much smaller and they
> > could be gone through in the usual way?
> 
> Personally, I've only "unilaterally" committed the things which I
> think can't possibly make anything worse. Even then, I've been wrong
> on a couple of occasions.
> 
> In retrospect, I think that we should have had a 5.1 branch for minor
> but ultimately non-trivial upgrades (e.g. the datum stuff), a 6.0
> branch for the more radical stuff (i.e. Radim's vector re-write), and
> kept 5.0.x strictly for bugfixes.

This sounds reasonable. It were also better not to introduce the
highly awaited datum transformation in the 5.0.x branch as it
is incompliant with the older data then.

The currently called 5.1 could become 5.9.x (to end in 6.0 then)
and the datum transformation (as well as the polished NVIZ?) go into
5.2.0 after a short period of 5.1.x.
 
> There are known actual bugs in 5.0.2; it would have been nice to have
> a 5.0.3 version which fixes the bugs in 5.0.2 with absolutely zero
> chance of breaking anything else in the process.
I agree.

> I'm fairly sure that
> both 5.0.1 and 5.0.2 added new bugs which weren't present in 5.0.0 and
> 5.0.1 respectively.
>
> E.g. 5.0.2 added a *major* bug to r.mapcalc, which could have rendered
> 5.0.2 unusable (actually, it might be unusable on some platforms; the
> only reason why 5.0.2's r.mapcalc works is that the memory obtained by
> malloc() early in the program is usually full of zeroes).

Like that we could go for radical improvement with 5.9/6.0 which are
definitely necessary for the future of GRASS.

Markus