[GRASS-dev] Re: Branching

[Markus Neteler]

On Wed, Aug 09, 2006 at 09:03:29PM +0100, Glynn Clements wrote:
> 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,

... apart from critical bugfixes which I and Hamish will take
care of...

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

Well, we have meanwhile advertised 6.1.0 quite a bit and people
are awaiting it more or less today (it's sitting already as tarball
on my PC). We have also the announcement ready to be published,
a job is currently creating a Mandriva RPM (other tomorrow) etc.
Of course I can stop that but I don't see any advantage in doing so.

We could add "technology preview" as earlier suggested by Hamish to
mentally prepare people that 6.2.0 is very close. And, as offered,
I am willing to backport critical bugfixes to 6.1.0 branch.

Markus

-- 
Markus Neteler  <neteler itc it>  http://mpa.itc.it/markus/
ITC-irst -  Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18        -       38050 Povo (Trento), Italy