[GRASS-dev] GRASS CVS to SVN migration: repository structure

Glynn Clements glynn at gclements.plus.com
Mon Dec 17 12:43:56 EST 2007


Paul Kelly wrote:

> >> Ideally the 6.3-release branch would be a branch from 6.x-devel, as
> >> that's how it's structured in CVS. But that may not be possible given
> >> that it existed prior to the migration to SVN.
> >
> > I wonder if we should sort of re-do the 6.3-release branch. I am not
> > aware of incompatible changes within HEAD yet. Maybe it is better
> > to branch off again (say, to bulk merge from HEAD/trunk into the
> > existing branch) to catch recent fixes for 6.3.0.
> 
> If such a bulk merge from the HEAD to the (as it currently is) 6.3 release 
> branch could be done, I think that would be a good plan and the 
> 6.3-release branch could be renamed to e.g. 6.x-devel and development go 
> on there---then the 7.x big changes could start on the HEAD.
> 
> Or the 6.3-release branch could be dumped (see below) and 6.x-devel 
> branched off the HEAD, leaving it free to be in effect "7.x-devel".
> 
> My main concern/doubt is that I don't see why 6.3 needs to have a release 
> branch at all at this stage. I thought release branches were only for 
> stable releases where the functionality needs to be frozen. As 6.3.0 is 
> going to be a development (not stable) release, it makes sense to me for 
> it to be a direct snapshot off the development branch or HEAD - similar to 
> the way the 5.0.0pre releases were done in the dim and distant past. If we 
> decide that 6.3.1 is going to be a stable release, or we call it 6.4.0, or 
> whenever, *that* is when we should be creating a release branch, IMHO.

The main problem with making releases from the trunk is that if
someone commits a change which ends up taking some time to get right,
we either have to postpone releases or revert the change. If we have a
separate branch, we can simply avoid merging that particular change.

-- 
Glynn Clements <glynn at gclements.plus.com>


More information about the grass-dev mailing list