[GRASS5] current release branch

Glynn Clements glynn.clements at virgin.net
Fri Oct 11 13:55:39 EDT 2002


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. :)

Bear in mind that the only things which I have committed to the
release branch have been bug fixes.

> > > 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.

Which is all that I've been committing. 5.0.1 ought to just be bug
fixes, so that it entirely supersedes 5.0.0. Any incompatible change,
however minor and however much it is considered an "improvement",
needs to be kept separate, so that users who value stability over all
else can still get bug fixes.

> > 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.

The advantage of performing the reformatting at the outset is that
developers don't have to download every file twice.

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




More information about the grass-dev mailing list