[GRASS-dev] Re: Branching

[Markus Neteler]

Hi,

could people live with the existence of a 6.1.x branch (maintained
for critical fixes) and a new 6.2.x branch (maintained for the
next stable release)? Everything is ready for 6.1.0. Michael and
others are waiting for the 6.2.x branch to be created to move the
Python interface into CVS HEAD.

I would really like to move on. But I dislike to not have sort
of consensus on it.

thanks
 Markus


On Thu, Aug 10, 2006 at 08:55:35AM +0700, Yann Chemin wrote:
> 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