[GRASS5] GRASS stable/exp branches

Markus Neteler neteler at geog.uni-hannover.de
Thu Feb 22 04:15:08 EST 2001


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. That
> means all bug fixes AND features merge with the stable, which is what we
> have now. I also see this as more work for you unless you get volunteers
> to help monitor the branches. Another point is when do we merge in the
> features?
Yes, that sounds reasonable. I definitly want to lower the extra work,
that's why we use CVS. ok: my proposal deleted :-)

> > 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. I don't think we should individually decide if each module is
> stable or not and add them one at a time. 

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, but eleiminate them from the binary ball by
commenting in src/CMD/lists/GRASS. We should carefully revise this list
now.

> What I thought was feasible
> was at some point when we want to create a release we create the branch
> on the whole tree at one time, at which point only bug fixes can be
> committed to the stable branch. Then we define which bugs will be fixed
> for this release, and once they are fixed we start our pre-release
> testing. If somebody commits a feature just before the branch is made
> and it has a bug, we are very likely to find it while we fix the bugs in
> our list. As for merging, we can either wait until we publish the
> release and then merge all bugfixes back to the exp branch, or we merge
> them back periodically during the bug fixing stage.
> 
> 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. This would even
simplify the 5.1 thing as we don't have three branches then.
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?

> 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.
> 
> Just my 2 cents worth
It' much more, Justin!

Thanks for the clarification.
Other comments?

 Markus

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



More information about the grass-dev mailing list