[GRASS5] Using CVS to manage "experimental" vs. "stable" trees

[Carl Worth]

On Apr 23, Glynn Clements wrote:
 > > At that point, if I understand things correctly, that release branch
 > > will not have any work done on it after that. The 5.0.1 release will
 > > not come from an extension of the 5.0.0 branch, but will instead be a
 > > new branch off of the trunk at some later time.
 > 
 > The 5.0.x releases should be made from the same branch as 5.0.0. They
 > should differ from 5.0.0 only in terms of bug fixes. It would be
 > possible to add new modules (which work with the existing libraries),
 > but I would suggest that developers work on the next major version
 > instead.

Glynn,

I agree that this is how things should be done.

I didn't advocate this in my original post, since I was trying to
stake out a moderate position without revamping everything about how
GRASS is being developed currently.

But, as long as you've brought it up now. ;-)

If a branch is created named RELEASE_5_0 along which we make some bug
fixes and get to a point which we tag RELEASE_5_0_0, then we can later
fix more bugs, (found by actual users not just developer testing), and
make later tags along this branch such as RELEASE_5_0_1 and
RELEASE_5_0_2.

Having a branch such as this which is restricted to strict bug-fixes
only is really the only way to guarantee extreme stability between
minor releases.

But, in this system, what then becomes of the head of CVS? Certainly,
more development would occur there, (or else, why create the branch in
the first place?), and it would reach a point at which it is ready to
be released. It would be natural, then to create a RELEASE_5_1 branch
and repeat the process.

However, this is highly confused by the fact that we already have a
module named grass51. (This is a problem in the existence of this
module, not in the scheme proposed above).

The fact is, when a developer sits down to write a piece of code, it's
impossible to predict a completion schedule, (especially the relative
schedule compared to other developers --- some of who may not yet be
on the project). Between now and the time Radim finishes the new
vector engine and it is ready to be included in the new stable release
of GRASS, how many different incompatible new features will other
developers create and want to release? Would we want to release 5.0,
5.1, and 5.2 before then? The answer is impossible to predict. Hence,
it's very dangerous to attach version numbers to things before they
are released, (release points are really the only time version numbers
make sense).

Instead of using a number like 5.1, (even an odd number), when doing
parallel development, it seems it would be better to name the
functionality being explored, (eg. database_backed_vector_engine or
whatever). And, as I put forth in my previous mail, such named
experimentation belongs in a branch rather than a separate module.

So, those are my thoughts on where we should ideally be some
day. Plans for moving from where we are today may have other more
pragmatic considerations, (though generally, when making big
improvements -- even painful ones -- sooner is generally better than
later).

Cheers,

Carl

-- 
Carl Worth                                        
USC Information Sciences Institute                 cworth at east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203		  703-812-3725