Merging to the release_1_6 branch

[Jordan K. Hubbard]

On May 27, 2008, at 12:48 PM, Rainer Müller wrote:

> If we would do this the way you describe, every new feature would  
> have to be developed on a different branch.

I think this depends entirely on what you call "a feature."   If by  
"feature" you mean "something which is going to take a long time to do  
and may or may not even result in success" then sure, you're going to  
put it on a branch.  You would have always put it on a branch, in  
fact, since a feature like this is disruptive even to other work in  
trunk so "good branch practices" still apply and what we're talking  
about doesn't even really matter to you since your modus operandi is  
going to be the same either way.

If, on the other hand, you are talking about "ongoing improvements and  
some amount of WIP" when you say "feature" then that's fine.  You can  
still absolutely release trunk periodically, after a convergence  
period, and have that kind of work going on in the VCS.  It just takes  
a bit of clear communication amongst the developers and the release  
engineer as well as a commitment to working that way, e.g. by  
following certain engineering practices like always having enough  
"configuration switches" in the tree such that WIPs can be turned off  
by default and only enabled by those wishing to participate in the WIP  
(and I'm not talking about anything complex when I say "configuration  
switches" - they can be everything from compilation options to crude  
developer-only runtime settings).

- Jordan