[GRASS-dev] Re: Branching

Yann Chemin ychemin at gmail.com
Wed Aug 9 21:55:35 EDT 2006


Maybe the "technology preview" is actually a good tag name for 6.1,
and it is well preparing people to receive 6.2. Maybe 6.2 can be
announced as beta in the news the same day of 6.1 release to reinforce
that feeling, maybe even announcing a 30 days target for 6.2 release.

In this way people that want to make a biggish use of GRASS will take
the beta and get going within a week or two with the RC releases of
6.2 instead of focusing on 6.1 itself.

On 10/08/06, Markus Neteler <neteler at itc.it> wrote:
> 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
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>




More information about the grass-dev mailing list