[GRASS5] The status of 5.0

[Bernhard Reiter]

On Fri, Mar 22, 2002 at 04:54:52PM +0100, Markus Neteler wrote:
> On Fri, Mar 22, 2002 at 04:22:39PM +0100, Markus Neteler wrote:
> > On Fri, Mar 22, 2002 at 02:26:06PM +0000, Glynn Clements wrote:

> > I am not sure if this cutting of release branch *without* releasing
> > GRASS was a shoot in the foot.

The files should be still there, thus nothing is lost.

> > Glynn may remember that the merge back of release_branch some time ago
> > deleted a set of new features added by Radim in v.out.shape and
> > d.what.vect. How should Radim restore that now (beside the slightly 
> > annoying extra work)? 

Just check it out of the branch.

> > Also, now we definitly have the I18N/L10N in
> > the next release branch source code.

As Glynn pointed out, I think we should disable it by default.
I consider this a big feature we should thorogly introduce in GRASS5.1.

> > PS: How can I somewhat automate the switch-on/switch-off of
> > the cvs snapshot scripts? 

If I correctly guess what you mean: You probably cannot.
And it is better this way. A manual intervention every month or so
should be fine as it probably is just on line to change.

> > Looks like another tons of work for
> > me, that the release branch is killed - rewriting scripts and
> > cron jobs, rewriting web pages etc.

We need management of this.
Actually we do this the first time and thus we can adopt our
infrastructure to suit this.

E.G. you could have files:
	Current release branch
and then use a script to update this at the right places.

> While continuing to think about eventual advantages for *us* with
> branching, there seems to be litte reason to continuing branching

> We have used branches for one year now, with no real advantages but
> a lot of extra work. The reason might be that we weren't using branches
> as intended, but we have the limiting factor of a small team.

I don't agree.
It is the opposite reasoning:
Because we have a small team, we need proper version control.

I agree that we are seeing some extra efforts while we are all
learning this and setting it up for GRASS.
It will pay off several times.

> The previous way (4.x) of having x.y.module and x.y.module2 is
> probably more obvious and less energy consuming.

Not in my experience with other big Free Software projects.

> At time I find branches a bit waste of time - the outcome is little.
> To create/delete release branches more frequently will even consume
> more of our energy.

We need the quality control badly.
Without branches we will have more confusion with the same number of
bugs, fixes, feature requests, experimental enhancements ...
Now you are sometimes forced to get the overview and decide
what to keep from all this mess. It might look like more work,
but it is badly needed to prevent even more work.

	Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 248 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20020322/99c157d9/attachment.bin