[GRASS5] GRASS stable/exp branches

[Bernhard Reiter]

On Thu, Feb 22, 2001 at 09:15:08AM +0000, Markus Neteler wrote:
> Hi Justin, hi all,
> 
> On Wed, Feb 21, 2001 at 05:53:49PM +0700, Justin Hickey wrote:
> > Markus Neteler wrote:
> [...]
> > Not quite to me, sorry. This setup is not much different than what we
> > have now - adding features and bug fixes to the branch we want people to
> > download. For example, say I fix a bug, but it requires changes to files
> > spread out all over the source code (I change the parameters of a
> > function call in the gis library). I will not want to merge each file
> > individually, so I do a general merge of the whole grass tree. 

It is not necessary.
You just tag your version and only merge the changes for your fix,
even when it is spread out. 

> Yes, that sounds reasonable. I definitly want to lower the extra work,
> that's why we use CVS. ok: my proposal deleted :-)

No, Markus, your proposal was a lot better. 

> > > There might be the idea to start a new stable from every time when we
> > > want to release a new stable version (so every stable branch is dead
> > > after publishing the individual stable version). This would make life
> > > easier in terms of less bugfix merging required, BUT: Every new stable
> > > branch needs that every module is tagged "stable" (or not). Means to
> > > visit 400 modules all few month, even if you know they are stable.
> > > Therefore I feel to have a continuous stable branch is better.
> > 
> > What does this really mean? I thought that to create a branch you simply
> > do a cvs tag -b command at the grass root and you let CVS take care of
> > the rest. 

This is basically true.

> > I don't think we should individually decide if each module is
> > stable or not and add them one at a time. 

Well we have to start to tag modules which we know are stable.
So there has to be one starting point for the stable branch.
And Markus has to decide which modules get in there.
Later we can add more when we know they are ready to be included.
To rephrase it again: Yes we have to decide which module is stable
and which not.

> The only question is: how to get instable code out of the stable release?
> For example: The entire G3D section should not yet go into stable.
> Then there are several modules to be commented. Probably we should
> keep them in src-ball, 

No. I advise against Justin's idea. :)

> > With this option, additional workload for monitoring both branches is
> > minimized since the two branches exist for only a short amount of time,
> > and it is easier to keep features out of the stable branch. Now we
> > create a branch, make it stable by not adding any features and this is
> > the code we want people to download.

> Ok, we have a sort of periodical stable branch then. 

We need one continous stable branch until 5.0.0 is released.
After that we have to rethink a couple of things. I also do not
think that we need the same setup for the 5.1 _tree_.

> This would even simplify the 5.1 thing as we don't have three branches then.

No, 5.1 has to become a fresh tree, no branch.

> However, this needs commit discipline: Only bugfixes are allowed 
> untilthe periodic stable branch is merged back after publishing the
> stable release. Did I get it?

True, and the other way gives you more control and is therefor saver.

> > I don't know if I understood you correctly, but this method seems safer
> > with less managment overhead to me than always maintaining a stable
> > branch.

I don't think so, we have the same problem as before, the control
over what bugfix gets in is not fine grained enough.

	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/20010222/5127dfa5/attachment.bin