Merging to the release_1_6 branch

[Blair Zajac]

Jordan K. Hubbard wrote:
> On May 27, 2008, at 11:52 PM, Rainer Müller wrote:
> 
>> But you would definitely tag that 1.7.0-rc1 not 1.6.1-rc1. And where  
>> do you fix a bug found in that rc1? On and trunk and you merge it  
>> back to the 1.7.x release branch
> 
> That's either truly one-dimensional thinking at work or you are now  
> merely working overtime try and invent reasons to branch. :-)
> 
> Who says that the only way to fix bugs is to branch?  You might just  
> as well decide to create 3 tags in a row on trunk, during a code  
> slush, or even declare it a release and fix the bugs in the next  
> release (which, hopefully, would also happen MORE OFTEN than they do  
> now because there would be less work involved).  That is what  
> "convergence" means.  You fix the bugs in trunk until things are  
> "release ready" and then you release it.  If you want to create  
> "release candidate" tags, then fine, create them on trunk also.
> 
> It may seem like a minor point of order we're arguing to everyone else  
> who is undoubtedly bored sick by the topic by now, but one process is  
> a lot more light-weight than the other and minimizes confusion (like  
> features being on the 1.6 branch that someone forgot to merge to  
> trunk, as was just noticed) since the default scenario is always to be  
> on one linear path, with branches being the specialized exception  
> rather than the constant-expense rule.  But hey, maybe Rainer here  
> wants to volunteer to be release engineer for the next 5 years or so  
> (it takes at least 2 years to figure out how to do everything right,  
> so it's a long-term commitment) and win the argument by default since  
> if he's signing up to do all the extra merge work, I will stop arguing  
> and get out of his way immediately. :-)

I think the amount of work to use a branch is overestimated.  It's not hard and 
very easy and safer then having everything in trunk and then having to do code 
freezes.

Blair