[GRASS5] current release branch

[Glynn Clements]

Bernhard Reiter wrote:

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

So, if the 5.0.x versions are going to include minor improvements,
what will the bugfix-only versions be called? 5.0.0.x?

There isn't much point adding code to a release branch unless it
actually gets "released"; at which point, you need to pick a version
number.

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

It's probably only a minor advantage for those who pay a flat-rate
charge, or whose bandwidth is supplied by their employer, or who
derive some form of revenue from GRASS. However, none of those apply
to me, so I consider it a more substantial advantage.

Apart from bandwidth, there's also the issue that it complicates the
processes of performing "cvs diff" between pre- and post-formatted
versions, or performing "cvs diff" between two pre-formatted versions
and comparing the output to a post-formatted version.

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