[GRASS5] GRASS stable/exp branches

Bernhard Reiter bernhard at intevation.de
Fri Mar 2 06:14:32 EST 2001


Hi Justin,
we are going in the right direction.



On Fri, Mar 02, 2001 at 02:43:39PM +0700, Justin Hickey wrote:
> > True.
> > But we want no new features before the 5.0.0 release.
> 
> Yes, so we create a stable branch now (or soon). Then the new features
> go into the main branch.

Yes. I suggest calling the new branch: release branch 
and the main branch is the stable branch with new features.

> My vote is to not add any more features to 5.0 at all. Any 5.0.x release
> in my opinion should only contain bug fixes which we may have missed for
> 5.0.0. Any new features will go into 5.1.

Yes.

> We agree on this. I was under the impression that you intended for the
> stable branch to continue to exist long after 5.0, 5.1, 5.2, etc. Thus,
> Markus would always have two branches to maintain. Sorry for that
> misunderstanding.

We have clarified this now. :)

> Yes, and to me, the easiest way to do that is to mark the current tree
> stable and comment out those modules considered unstable from the
> src/CMD/lists/GRASS file. We can decide stability on a module-by-module
> basis when we create the new directory structure for 5.1.

I think we have to leave out the modules which we know are unstable.

> > > Furthermore, is
> > > Markus willing to tag 300+ modules individually?
> > 
> > He will have to go through all the modules ones and build a tree for
> > the first tagging. But yes, he has to check on each modules once.
> > There is no way around it. Most modules will be easiy to categories
> > and then not much else changes so there is not much tagging work to 
> > do.
> 
> Not necessarily. There are two ways to approach this. We can assume that
> we do not trust any module to be stable and Markus will have to check
> each one himself. Or, we can assume that most modules are stable and
> find the unstable ones through bug reports during pre-testing and post
> release time. 

WHu should just start form a fresh checked out tree and remove
everything he knows which is unstable. Then we can use your second
method. You are right that the other way around might be too hard to do.


> 1. Insist that the developer who committed the code back it out using
> log files to determine which files to back out.
> 
> 2. Have a cron job to tag the stable tree once a day (or some other
> regular time frame).
> 
> 3. Insist developers tag the stable tree before they make any changes
> and then tag it again after they make their changes (as you suggested
> above).


We need number 3.
	Bernhard


-- 
Professional Service around Free Software                (intevation.net)  
The FreeGIS Project                                         (freegis.org)
Association for a Free Informational Infrastructure            (ffii.org)
FSF Europe                                            	  (fsfeurope.org)
-------------- 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/20010302/3760447c/attachment.bin


More information about the grass-dev mailing list