[GRASS5] current release branch

[Bernhard Reiter]

On Fri, Oct 11, 2002 at 06:55:39PM +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. :)
> 
> Bear in mind that the only things which I have committed to the
> release branch have been bug fixes.

I know, still it needs a test period before release.

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

Our plan was to only have "critical bug" fixes on the release branch.
Minor improvements have to possible in the 5.0.x line.
Otherwise we paralize development too much. At least this was feared.
And then there are bugs that basically somewhere in between
a real bug and an improvement.

Additionally, even if we come up with new arguments,
we should stick with this plan at least for a while for consistancy
reasons before trying new schemes.


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

Well true, but I think of this as a minor advantage.
-------------- 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/f7897912/attachment.bin