[GRASS5] The status of 5.0

[Glynn Clements]

Bernhard Reiter wrote:

> > > On the merge:
> > > Glynn also posted a couple analysis of the differences of the 
> > > two branches in GRASS5. Glynn: Maybe you can propose how to completly
> > > discontinue the old release branch. You might also just do it if
> > > nobody else objects.
> > 
> > My preference would be to just sync any outstanding changes into the
> > trunk then declare the release branch to be dead 
> 
> Yes. Can you progress this?

Done, AFAICT.

> > (possibly renaming
> > the tag so that changes aren't committed to it inadvertently).
> 
> We have to slap developers on the wrist for committing changes to
> this branch!!! They will have to put it in the right branch again.

I've renamed the tag, so any attempts to checkout, update or commit
using the releasebranch_11_april_2001_5_0_0 tag should fail.

Use "cvs update -A" to update a release tree to the trunk.

Apart from the presence of additional code in the trunk, the
differences between the trunk and the release branch are:

1. d.area has been changed, and disabled (eric)
2. v.alabel/v.llabel changes (eric)
3. Addition of d.vect.area, d.vect.line, s.mask (eric)
4. configure checks for internal/postgres_fe.h (alex)
5. I18N/L10N of grass.postgresql/*, s.surf.rst (alex)
6. d.dm changes (radim)

The changes to the trunk are:

1. g.manual fixes sync'd from release branch (andreas)
2. g.help HTML generation (andreas)

> > Modules which shouldn't be built due to outstanding bugs should just
> > be disabled in src/CMD/lists/GRASS, rather than actually omitting the
> > source code.
> 
> When we have the new release branch, 
> we might as well remove them from there.
> There is no point in shipping modules with release critical bugs.
> This should also put some pressure on people to fix them.

My reasoning is that, if we include the source code for the disabled
modules, it may increase the chances of people fixing them. Otherwise,
anyone considering fixing a module first has to obtain the code from
CVS, which may discourage potential contributors.

-- 
Glynn Clements <glynn.clements at virgin.net>