[GRASS5] The status of 5.0

[Glynn Clements]

Radim Blazek wrote:

> Even if we have 2 branches (MAIN and stable), I cannot
> tell to user that he can use "new" v.out.shape because he has probably stable
> branch installed. If we had v.out.shape2 in one branch I can tell him that he 
> can use unstable version:
> cd src/mapdev/v.out.shape2
> gmake5
> gmakelinks5
> 
> Instead I have to tell him: 
> "You have to compile code from MAIN branch -
> you know, that branch which is not tagged releasebranch_11_april_2001_5_0_0
> (also called release branch). So you have to check out whole MAIN branch from
> repository - it is quite easy - just read CVS manual and instructions for 
> GRASS CVS. Then you must compile grass MAIN tree. Compiled tree takes only 
> about 500 MB - it is not problem. Now you must close your grass session
> and start grass from MAIN tree you have just compiled. You can run
> v.out.shape, exit grass and start grass stable. It is quite simple."

It shouldn't be quite as bad as that, in that you should be able to
obtain just the module in question from a different branch. But, yes,
it is more complex than having an alternate version in a different
directory on the same branch.

Also, some people may not be able to use CVS, e.g. because they are
behind a firewall.

> Other contributors are not interested in branches question? Can you vote?
> Branches for 5.0.x yes - no; Glynn, Eric, David, ....

Well, anyone with CVS write access can create a branch. But I don't
think that there should be more than one "official" branch.

If a developer wishes to create a branch to hold some experimental
changes, then fine. But it's up to that developer to:

a) keep track of any changes which are occurring on the official
branch, and

b) ensure that the other developers are kept informed of their
intentions.

That way, it should be possible to subsequently merge the two.

Otherwise, you get the situation which occurred with v.out.shape. The
two branches had changed in different ways, so that neither set of
changes would apply to the other version. The result was that only one
set of changes could survive, and the other set had to be discarded.

The real problem was that both branches were equally "official",
resulting in an expectation that changes to either would be accepted.

For "release" branches, you realistically need an active maintainer to
be responsible for managing that branch. They would need to track the
main branch, and apply those changes which are appropriate for a
release branch (i.e. bugfixes, and maybe some straightforward
enhancements, but not significant structural changes). If the main
branch starts to diverge to the point that automated merging produces
conflicts, the release maintainer may have to start making the changes
manually.

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