[GRASS5] Splitting GRASS 5 into stable and unstable

[Eric Mitchell]

"When To Branch" is one of those fundamentally  tricky 
questions of software development.  As far as CVS 
itself knows,
a branch is just some extra numbers on the front of
the file revision sequence.  The philosophical matter of
when to branch is the tricky part.

What this branch is trying to accomplish is (as I understand
it, feel free to correct me here) to protect the architectural
integrity of the pending grass-5.0 release.

The fundamental question here is (again, IMHO) "Are
there pending significant changes to the grass-5.x 
code base?"  I haven't followed the developer list 
long enough to know the answer to this.

If the only changes currently pending are bug fixes, 
and the base module set compiled by default, I personally
wouldn't branch yet.  If someone has, say, a more efficient
implementation of various raster file processing that looks 
ok, but needs some more "mileage" on it before considering 
it stable, I'd consider creating a branch so that work 
could be integrated into the source tree without affecting
the pending stable release.

Once a branch is created, especially in the case of "bug 
fixes in this branch, potentially unstable development in
this branch" cases, it is IMPERITIVE that someone track
the bugfix branch, and occasionally merge bugfixes back 
into the development branch.

Operationally, I recommend using symbolic tags at every
point you merge stable patches into the development branch.
This allows you to keep track of them like "merged stable 
bugfixes from rel_5_0_1 to rel_5_0_3" in your ChangeLogs,
or development documentation mechanism.

I can go on here, if anyone is interested, but I'm more
interested in feedback on whether others think this is
 a) reasonable criteria for determining whether to branch
 b) if so, whether there are sufficient pending developments
    to justify branching on those merits.

David D Gray wrote:
> 
> Markus Neteler wrote:
> >
> > Hi developers,
> >
> > from a personal discussion with Bernhard Reiter it
> > seems to be a good idea to start branches (hi David!).
> >
> > Due to the substancial changes awaiting for us we
> > should start a "developers version 5.1.0" very
> > soon. Do we need a "branch guide" for this?
> >
> > Markus
> 
> Hi Markus, developers
> 
> I am not an expert on CVS by any means, but from my reading
> of the info manuals on branching, that method is suited to
> development where there is a gradual change in files and
> the directory structure is more or less static. The changes for
> Grass 5.1.0 seem to involve major changes to the overall
> directory structure, so perhaps what we really want here is a
> separate directory tree for the development branch. (Then you
> would work in whichever directory was appropriate).
> 
> After that the only changes to Grass 5.0.x would be bugfixes and
> possibly additions or deletions of a few high level modules, but
> no change to the underlying structure. This would be a bit like
> the `frozen' stage, to borrow a term from Debian GNU/Linux.
> 
> David

-- ebm
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
| Eric B. Mitchell         mailto:emitchell at altaira.com |
| tel: (301) 809 - 3534    Altair Aerospace Corporation |
| tel: (800) 7 - ALTAIR    4201 Northview Dr. Suite 410 |
| fax: (301) 805 - 8122    Bowie, MD  20716             |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
              ,___
          /"\  / o=\  /"""---===/
         /   \_/  \__/   ---===/ 
         |    //\   || /""TT""/ //\   || ||""\
         |   //  \  ||    ||   //  \  || ||__/
         |  //--==\ |L--/ ||  //--==\ || || "=,
          \      ---===/
           \____---===/

---------------------------------------- 
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 5041
max: 0