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

[Martin Landa]

Hi all,

2007/12/11, Glynn Clements <glynn at gclements.plus.com>:

> > > > I'm unclear on how further 6.x development is to be handled.
> > > >
> > > > In the medium term, I would expect there to be futher development on
> > > > 6.x culminating in a 6.4 release. This will need to occur on a
> > > > separate branch to 7.x. E.g.:
> > > >
> > > >         +----+----> 7.x-devel
> > > >              |
> > > >              +----+----+--------> 6.x-devel
> > > >                   |    |
> > > >                   |    +----> 6.4-release
> > > >                   |
> > > >                   +----> 6.3-release
> > > >
> > > > The 6.x-devel and 6.3-release branches would be created immediately,
> > > > with 6.4-release created once 6.x-devel has accumulated changes which
> > > > cannot go into the 6.3.x releases.
> > > >
> > > > The trunk would become 7.x-devel, and would quickly change to the
> > > > point that merging changes with 6.x-devel would become impractical.
> >
> > Martin wrote:
> > > proposal...
> > >
> > > +--+-----+-----> 7.x-devel (trunk)
> > > |    |      |
> > > |    |      +------> 6.4-release (branch) <--- should be created [ASAP]
> > > |    |          |
> > > |    |          | backports (6.4 -> 6.3)
> > > |    |          |
> > > |    +-------------> 6.3-release (branch)
> >
> >
> > I much prefer Glynn's proposal.
> >
> > 6.3.0 release branch is not meant to be a stable branch. We can fix bugs in it,
> > but if its purpose is to help get the MS Windows stuff tested, then that's a
> > lot of backporting from 6.x/HEAD when we get ready for 6.3.1. (or just make
> > 6.3.1 a new branch from 6.x/HEAD). I consider it like 6.1.0, ie a dead-end
> > preview release.
>
> 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)

> 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.

Martin

> >
> > There should be no need to port stuff back to 6.3 r.b. once we have a 6.4 r.b.
> > >From then on we call the new preview releases 6.4beta1, etc. and forget 6.3.
> >
> >
> > We will need some strong discipline to put all new development into 7.x/HEAD
> > and backport interesting things to 6.x/HEAD; not the other way around.
> >
> Backporting from 7.x to 6.x is likely to be somewhere between hard and
> impossible, hence the need to maintain a 6.x-devel branch for the
> medium term.
>
> One of the first things which I want to do for 7.x is to globally
> re-format all code to a common convention. That alone will cause
> problems with merging.

-- 
Martin Landa <landa.martin at gmail.com> * http://gama.fsv.cvut.cz/~landa *