[GRASS5] Splitting GRASS 5 into stable and unstable

GRASS GRASS developer
1

Dear Developers,

as GRASS 5 becomes partly stable, it will be a good idea
to release a stable and a developers version.
As discussed with Bernhard, a GRASS 5 numbering scheme
analogous to the Linux numbering scheme would be useful:

Odd number for development versions, even for stable versions:
      5.1.0 is the first development tree release
      5.0.0 is the first stable release

The stable release should contain *only* working modules.
So the number of modules would be reduced comparing to
the development tree.

Another reason for the version splitting is the forthcoming
substancial changes in source code structure:

- GRASS must be split into packages (GRASS-Core, GRASS-Hydrology,
   GRASS-...)
- auto-conf shall be included for every module (new Makefile
   mechanism) [Eric may take care for this]
- a new display system shall be included [Pierre and Carl already
   work on this topic]
- ...

Due to these heavy changes GRASS 5.1.0 (devel) might become less
stable as GRASS 5 beta8 (or 5.0.0) for some time. But this code
structure update is necessary.

Your comments are welcome!

Markus Neteler

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

2

On Thu, 4 May 2000, Markus Neteler wrote:

as GRASS 5 becomes partly stable, it will be a good idea to release a
stable and a developers version. As discussed with Bernhard, a GRASS 5
numbering scheme analogous to the Linux numbering scheme would be useful:

Odd number for development versions, even for stable versions:
      5.1.0 is the first development tree release
      5.0.0 is the first stable release

Markus,

  I support this wholeheartedly. Perhaps the stable modules in 5 could be
repackaged as grass-5.0-rc1 (Release Candidate 1). When it's complete
enough for release, off it goes as grass-5.0.

  New modules could be accumulated as they are debugged, then a group of
them could be released as 5.0.1, the next batch as 5.0.2 and so on.

Due to these heavy changes GRASS 5.1.0 (devel) might become less stable as
GRASS 5 beta8 (or 5.0.0) for some time. But this code structure update is
necessary.

  In the meantime, code changes (data format, too) to the released modules
form the core of grass-5.1.0. Those who have the inclination, and time, to
focus on the developmental code can do so while those who need a production
release would have that, too. Personally, I need both.

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
              Making environmentally-responsible mining happen. (SM)
                       --------------------------------
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com

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

3

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

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

4

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

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

5

"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@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@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 5041
max: 0

6

Hi developers,

thanks Eric for your comments. As being far away from a
CVS expert, I am very interested in comments!

It seems we have to judge if we the planned updates
are significant changes in structure or not.

What I expect to be updated soon is (I hope it will happen):

(1) better/new makefile support:
      - auto-conf fully applied
      - split GRASS into thematic modules which could be downloaded
        and added to "GRASS-Core" on demand could be feasible
      - using shared libs (*if* recommended)
      - the make process should ignore missing modules to
        support GRASS modularity (in case the user downloads only
        part of the code)

(2) new XDRIVER2:
      - layer technology
      - socket support instead of fifos (to run faster and optionally
        on Windows platforms)

(3) clusterGRASS:
      - in case someone wants to improve/rewrite parts of
        GRASS to allow parallel computing: is it an own
        project or can it be done within the standard
        package (checked by auto-conf)?

Eric, as you are working on "auto-conf" support: Does it require significant
structural changes or not? In case we apply your patches directly, do we get
it stable soon (say: one or two month)? Is a new internal structure required
or updates only?

Concerning the proposed GRASS modularity:
I guess some of you know "R": They provide so-called third party
extensions which can be easily included. The local documents are
updated automatically with all cross references etc. It is quite
nice: http://cran.at.r-project.org/
http://cran.at.r-project.org/src/contrib/PACKAGES.html

This is more the bazaar type than cathedral... (well, this discussion
is another topic).

The short history of GRASS 5 was mainly updating, bugfixing and
prototyping. Now it will be time to go for above changes.

To conclude: In case we can apply above improvements, to you
think we have significant changes? If not, we may not need
a new parallel version and/or branches.

Hoping for further comments

Markus Neteler

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

7

On Tue, May 09, 2000 at 11:54:42AM -0400, Eric Mitchell wrote:

"When To Branch" is one of those fundamentally tricky
questions of software development.

I am almost certain that we need to branch.
That means, we need a road leading to a very stable grass5.0
and another that leads to new development version and a cleanup
of grass. But I agree that it is a tricky question.

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.

Yes.

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.

Again, yes. Markus pointed them out in his next post.

If we agree that we need a stable and a development tree we have
at least two technical options of implementing the scheme.
One is to use the branch feature of CVS, the other is to
create a parallel fresh module tree in CVS.

David was raising exactly this issue.
And this is another difficult question. I tend towards the
cvs branch method right now. Structural changes will still be possible
within CVS. You can remove files from certain cvs branches.

I assume that even in the development version a lot of GRASS huge
codebase and filesnames will stay the same. The technical advantage in
using CVS branchen then is, that only the changed files and directories
actually will be kept two times in the repository. And it will be
possible to merge generall patches relatively easy. It is also a lot
easier to switch to a seperate CVS tree from a CVS branch as the other
way round.

Just my 0.02 Euro,
  Bernhard

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

8

To Grass developers list,

I have used CVS from 1991 to present. I oversaw the work of
25 different project teams, about 65 feds and 125 contractors
for USDA NRCS as a configuration manager. I also have
built CVS for ARS and recently worked with them to configure
their CVS as well as use the jCVS and WinCVS clients. I
have given CVS training in the last two years to three different
groups.

Doing branches is necessary when there are code changes that
break the system. Making fixes or patches to the HEAD of
a CVS repository do not usually require a branch. Communication
such as the recent CVS announcement by Bernhard is one
of the key elements of using CVS together. So, the question
to ask is what breaks the system?

Any code that changes a function name, function variables,
number of function variables, adds new external variables,
and like scenarios is cause for making a branch. New code
that uses the older code does not require a new branch.
Further, branching can be done by any individual but merging
is done by the group. Announcing before-hand that a merge
is about to happen (so we can all update our local files
first!) is being handled great by Markus.

John Huddleston, P.E.
USDA Computer Engineer
huddleston@gpsr.colostate.edu
(970) 490-8352

----- Original Message -----
From: Bernhard Reiter <bernhard@intevation.de>
To: <grass5@geog.uni-hannover.de>
Sent: Tuesday, May 09, 2000 3:43 PM
Subject: Re: [GRASS5] Splitting GRASS 5 into stable and unstable

On Tue, May 09, 2000 at 11:54:42AM -0400, Eric Mitchell wrote:
> "When To Branch" is one of those fundamentally tricky
> questions of software development.

I am almost certain that we need to branch.
That means, we need a road leading to a very stable grass5.0
and another that leads to new development version and a cleanup
of grass. But I agree that it is a tricky question.

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

Yes.

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

Again, yes. Markus pointed them out in his next post.

If we agree that we need a stable and a development tree we have
at least two technical options of implementing the scheme.
One is to use the branch feature of CVS, the other is to
create a parallel fresh module tree in CVS.

David was raising exactly this issue.
And this is another difficult question. I tend towards the
cvs branch method right now. Structural changes will still be possible
within CVS. You can remove files from certain cvs branches.

I assume that even in the development version a lot of GRASS huge
codebase and filesnames will stay the same. The technical advantage in
using CVS branchen then is, that only the changed files and directories
actually will be kept two times in the repository. And it will be
possible to merge generall patches relatively easy. It is also a lot
easier to switch to a seperate CVS tree from a CVS branch as the other
way round.

Just my 0.02 Euro,
Bernhard

--
Professional Service around Free Software
(intevation.net)
The FreeGIS Project
(freegis.org)
Association for a Free Informational Infrastructure
(ffii.org)

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