Merging to the release_1_6 branch

[Jordan K. Hubbard]

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

- Jordan