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

[Glynn Clements]

Martin Landa wrote:

> > There may be some confusion with terminology. Currently, we have the
> > 6.2-release branch (releasebranch_6_2), the 6.3-release branch
> > (releasebranch_6_3) and the trunk serving as 6.x-devel.
> >
> > I'm proposing that we immediately create branches for 6.3-release and
> 
> ? maybe I am wrong but branch for 6.3-release already exists (releasebranch_6_3)
> 
> > 6.x-devel, with a 6.4-release branch eventually being created as a
> > branch of 6.x-devel.
> 
> so it means (AFAIU)
> 
> +--+-----+-----> 7.x-devel (trunk)
> |  |     |
> |  |     +----------------------------+----------------------------> 6.x-devel (branch) <--- create *now*
> |  |        |                         |     |
> |  |        |                         |     | backports (6.x-devel -> 6.4)
> |  |        |                         |     |
> |  |        |                         +-------------> 6.4-release (releasebranch_6_4) <--- create later
> |  |        |                               |
> |  |        | backports (6.x-devel -> 6.3)
> |  |        |                               |
> |  +-------------> 6.3-release (releasebranch_6_3)

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.

> > IOW, we need both 6.x and 7.x development branches (one of which would
> > be the trunk), in addition to any release branches. We don't need a
> > 6.4 release branch yet.
> > > 6.4 requires a stable wxGUI, this isn't going to happen instantly. Porting
> > > everything from 6.x/HEAD back into the 6.4 r.b. for months seems like a huge
> > > waste of effort. Thus I think creating a 6.4 release branch ASAP is a mistake.
> > > Let's do it when the code it ready.
> 
> I guess 7.x-devel should be trunk, I meant to create releasebranch_6_4
> as 6.x-devel branch, it would make things more simple. The development
> for 6.x would be in releasebranch_6_4 which would become last branch
> of 6.x. Creating branch 6.x-devel right now and later creating
> sub-branch releasebranch_6_4 is more clear, but a little bit more
> complicated, see the diagrams above.

The general principle is that no development occurs on a release
branch.

Development occurs on a development branch (or the trunk). When it is
deemed time for a new series of releases, a the development branch is
forked to create a release branch, and a snapshot of the release
branch is created to form the first release candidate. Thereafter, the
only modifications to the release branch are made by merging specific
changes from the development branch to the release branch. The various
release candidates and releases are snapshots of the release branch.

This means that changes whose desirability is uncertain can be made to
the development branch. If they work out, they get merged onto the
release branch. If they don't work out, they simply don't get merged;
there is no need to explicitly back them out to obtain a stable
version for release.

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