[GRASS5] current release branch

[Bernhard Reiter]

On Fri, Oct 11, 2002 at 08:56:39PM +0100, Glynn Clements wrote:
> 
> 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?

This comes down on what a bug fix is.

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

Yep, there is not much point to add code the the branch now.
5.0.1 will be basically a bug-fix release in about three month.
But this does not mean it won't have any improvements in.

As written above if we want to make a critical bugfix-only release
fast (next week) we could utilise the old release branch once more
and call that release 5.0.1. But _only_ if we have major critical bugs.

The whole issue is about how critical a bug or improvement is
and what the time frames are. Of course I do appreciate your efforts
to speed GRASS releases up again, but we still have chew on 
having a stable and a development line. We just did the first stable
release of GRASS 5! :)


[ about reformatting ]


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

If we stick with reformatting when a human will control it,
which basically means relaxed reformatting you will not
have to download all files a second time a once.
-------------- 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/c03b3b10/attachment.bin