>> In the worst case, I think it would be a good idea to at least create a
>> temporary "development branch" where patches can be pushed while the
>> hard freeze is in place for v14.0.0. After v14.0.0 is released, the
>> changes made can be merged into the main trunk.
>>

> I am afraid that with the branches is the same as with the tags - after
> creating on the server branch synchronizes to users, but after remove on the
> server users will have to worry about removing branch == all the users
> themselves. This is not good. Therefore, I am not a fan of temporary branches
> on the server.

The temporary branch would be just for us developers, not for the main users, to be able to comtinue development. And given that we are just 5 people, I tihnk it would be managable. 
Nevertheless I would still prefer to branch as you described in option 2 earlier today.


Tim, I don't know how the build farm works internally, but perhaps the following idea could be useful.
- create a file with the list of all modules that should be built. For each module indicate whether to build against the current source in the master branch or against a particular GIT hash in a particular branch.
- modify the build process to read the file above and checkout the proper branch and commit for each module, then build the module
In this way, when we want to build "standard" nightly build packages, we just say to build againast the current source and master branch
When we want to build a specific image (for example RC1, RC2, v14.0.0 and later versions) we use a different index file which contains the correct information for such build. This would also to build different "versions" any time we want.

Just an idea, as I said I do not know the internal mechanisms of the build farm.
Cheers
  Michele