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

Hamish hamish_b at yahoo.com
Sun Dec 16 21:16:58 EST 2007


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

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

we have already gone to the trouble of having the RCs, so why not just tag
6.3.0 *now* from releasebranch_6_3, close that branch and tag a 6.3.1
from from the 6.x devel branch (be that trunk/ or its own branch by then)
sometime after all the migration dust settles? (early february?) As long
as we clearly note it is a beta release which is expected to contain
problems...

> Glynn Clements wrote:
> > The general principle is that no development occurs on a release
> > branch.
> 
> The general scope should be to fade out 6.x *development* (keep
> maintenance) and focus on GRASS 7. Given our limited resources, I don't
> see an alternative. We all would like to make so many major changes to
> GRASS that this cannot happen in the 6.x line but in 7.x only. So let's
> start!

go go go!

but first...  have we settled on a branch plan?

my 2c version (where "my" = assimilating the ideas of others):
 order of action something like:
  [now, or in the next weeks as holiday time allows]
  1. tag 6.3.0, ship it, forget it
      -6.3.1 from releasebranch_6_3 only if 6.3.0 is a brown paper bag
        (the goal is a stable 6.4, not maintaining a stable 6.3.x)
  2. create 6.x limited-devel branch
      -6.3.1 from that (b or t?), leading to a releasebranch_6_4 from
       which 6.4.0RCx and 6.4.x releases will be cut.
       create releasebranch_6_4 the same day as 6.4.0rc1 is tagged.
  3. label trunk/include/VERSION as 7-dev code

  [time passes]
? 4. backports to & releases of 6.2.x, 5.4.x, 6.4svn as needed *FROM 7*.


I am still unsure how we fill the usability void that "make mix" looked
after for grass 5.1/5.7, while 7.x is undergoing major changes and not
suitable for day to day "production" use.
-- related: what's the best way to backport to branches in SVN?
   (replacement for 'cvs up -j HEAD ...')


suggestions,
Hamish


More information about the grass-dev mailing list