[GRASS5] The status of 5.0

[Markus Neteler]

On Fri, Mar 22, 2002 at 11:24:11AM -0700, Roger Miller wrote:
> 
> On Fri, 22 Mar 2002, Glynn Clements wrote:
>  
> > Actually, I suspect that's likely to be a catch-22 situation. In order
> > to become truly fixed and completely stable, 5.0 needs a lot more
> > testing than it will get while it remains "in development". To get an
> > adequate level of testing, it will need to be put into real-world use;
> > which probably means declaring it to be "released".
> 
> I doubt that the general public wants to be your beta-testers.  It sounds
> to me like what we actually need is a systematic means of testing the
> software.
> 
> Besides, I doubt that just calling 5.0 "stable" is going to net very many
> more users then it has right now.  To the extent that new users do try it 
> we're likely to lose new users, because the software *isn't* stable.
> The fact that you would even suggest that several minor releases would
> immediately follow the initial release just proves that it isn't stable.

This sounds like a small conflict between the "release often" and the
"release stable" paradigm...

I just want to point out that the GRASS community seems to be very
conservative about versions. I am quite sure that several users still
use 4.1 (from 1991). At least 4.3 is widely in use because people
see that it is called "stable" (IMHO the 5.0pre3 already works better).
The effect of giving a software a certain name in GRASS community
should not be underestimated.

And: what means stable for a modular system? I think stable means that
basic functionality the average user expects from a GIS is working
(oops, we don't have good cartographic output etc.) If an exotic module
is not working, that's not a problem for a stable release. Even in
GRASS 4.x several modules are not working properly.

I suggest that we really collect the bugs in RT with priorities, then
follow this list sorted by priority and that's it. Then we can release.
Due to above mentioned community responses, I only expect a real migration
to 5.0 from an official release. We can comment weak modules in the
compile list, however, ship them with source code. Like that we can
achieve binary releases which contain working modules.

We should not delay the stable release forever, by limiting functionality
through commenting from compile list and fixing the remaining essential
modules we should go ahead.

Markus