[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