[GRASS-dev] Re: Branching

[Michael Barton]

I can live with it. No problem

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Markus Neteler <neteler at itc.it>
> Date: Thu, 10 Aug 2006 22:11:03 +0200
> To: <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] Re: Branching
> 
> 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
> 
>