[GRASS5] current release branch

[Bernhard Reiter]

On Thu, Oct 10, 2002 at 07:50:16PM +0100, Glynn Clements wrote:
> Bernhard Reiter wrote:

> > Can I take this as pledge for a relatively fast non-critical 
> > release of 5.0.1 based on the release branch?

> I would like to see 5.0.1 released sooner rather than later, as we
> already have an initial "batch" of bug reports to process.

Each release needs to have a test period.
I think a two month plan which usually gets executed in three month
is pretty fast to have another stable release. :)


> > The alternative would be to finish 5.0.1 up more properly.
> > We would have one month open development (minor new features,
> > minor bugfixes) on HEAD than create the 5.0.1 release branch
> > and go to bugfixing only on this branch and release after a month.
> 
> I wouldn't do a "5.0.1 release branch". The more logical course is to
> merge the fixes into the generic "release branch", so 5.0.0 and 5.0.1
> would just be two different snapshots of the same branch.

We've deceided against a "generic" release branch a while ago
and I hope we stick for the plan at least for a couple of releases
to see how that works out. The release branch will only be for 
testing and fixing release critical bugs.

> IMHO, all "development" should be moved to 5.1. But first we need to
> sort out the specifics of the transition.

Again we have a special situation with GRASS here.
Some development must be allowed on 5.0 and this is basically
possible on HEAD all the time. However we want encourage people to
help move GRASS over to 5.1 and mainly improve the structure.
So radically new things should not go on 5.0 only bug fixes and 
_minor_ feature development.

So goal is to get GRASS 5.0.x a very stable line
in the current structure (including the structural drawbacks).

> One issue which should be settled first is to choose a common coding
> convention. That way, we can populate the 5.1 tree with files which
> have already been formatted, so that everyone doesn't end up
> downloading the same files twice (reformatting tends to change every
> line, so "cvs update" will retrieve the entire file).

The file structure should come first and library normalisation second.
This goes along with a proper makefile system.
Coding convention is third.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20021011/bc8763dd/attachment.bin