[GRASS-dev] GRASS CVS to SVN migration: repository structure
Martin Landa
landa.martin at gmail.com
Wed Dec 12 05:30:34 EST 2007
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 *
More information about the grass-dev
mailing list