Hi all, 2007/12/11, Glynn Clements <[EMAIL PROTECTED]>:
> > > > 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 <[EMAIL PROTECTED]> * http://gama.fsv.cvut.cz/~landa * _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
