Branching - was Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2

[Glynn Clements]

Markus Neteler wrote:

> On Wed, Aug 09, 2006 at 05:08:08AM +0100, Glynn Clements wrote:
> > Markus Neteler wrote:
> > 
> > > > But the 6.1 branch is less than a month old. How many fixes can there
> > > > be which can't easily be merged into 6.1.x?
> > > > 
> > > > I'm not sure that having two stable versions based upon HEAD snapshots
> > > > only a month apart makes sense.
> > > 
> > > I don't see a big difference (result) between
> > > (a) branching again
> > > (b) merging many things back
> > 
> > The difference is that (b) allows you to choose which changes to
> > merge, i.e. include simple bug fixes but not more destabilising
> > changes.
> > 
> > > The latter is much more effort. I currently have no time to
> > > do more backporting of changes. That's why I proposed (a).
> > 
> > In that case, my inclination would have been to simply move the 6.1
> > branch tag to the point where 6.2 would have been created. There
> > doesn't appear to be much point in having an isolated 6.1 release for
> > which any bugs will never be fixed.
> 
> Sounds absolutely reasonable to me. It wasn't clear to me that
> this is possible (I only knew about tag shifting; since a branch is
> more or less a tag it maybe works the same way?). Have to
> get out my CVS book for that if noone else shifts the branch.

Hmm. The cvs Info file says:

  *WARNING: Moving branch tags is very dangerous!  If you think you need
  the `-B' option, think again and ask your CVS administrator about it
  (if that isn't you).  There is almost certainly another way to
  accomplish what you want to accomplish.*

So maybe that isn't such a good idea. It would be safer to just add
another tag and forget about the old one.

> > For me, the main question is: what would be the reason for a user to
> > choose 6.1.0 over 6.2.0?
> 
> No real reason despite the time lag (6.1.0 we can have today,
> for 6.2.0 we would make a beta first). Again, I think that
> there are some relevant changes which 6.2.0 do not want to miss
> (means: no simple rename of 6.1.0 to 6.2.0) such as no more
> low limit of open raster maps, MingW/Cygwin fixes and other recent
> things. We should keep in mind that 6.2.x will be around for a while
> and that e.g. QGIS builds on top of it. For distros like Debian, Gentoo,
> Mandriva where packages depend on each other this makes a difference.

If 6.1.0 will never have any updates, it would probably be a bad idea
to build on top of it or use it in an OS distribution. The first
significant bug would necessitate switching to 6.2, so you may as well
just skip 6.1 altogether.

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