Nothing here contradicts what I said. You do most of the work on the main branch. You then either stabilize on the main branch or branch for a VERY brief time to stabilize then merge back. This branch should not be live for longer than two or three days, a week at most. When you release, you then branch. Hot fixes, etc are applied on the branch and on the mainline. One key concept is the life of this branch eventually ends, meaning you no longer patch or support that version. Work on the next version is done on the main branch.


>I may have misunderstood you, but if not: I would disagree. I believe it is good practice and very common to create a branch at each release. Then new enhancement code continues to go in the main branch for the next release and you have a stable release branch in which to apply any hot-fixes for that release without risking implementing the next targeted release code. Some companies do all coding in the main branch and only apply hotfixes to release branches (they retain that branch as along as in use or required for auditing if their customer base is governmental) and only critical bug fixes go in them for subsequent partial updates) and others the main becomes the release and they code in the next release branch. I have seen both. Similar to:
>
>http://msdn.microsoft.com/en-us/library/bb668955.aspx
>
>Scenario 2 – Branch for Release. Your team creates branches to support an ongoing release. This is the next most common case where you need to create a branch to stabilize for a release. In this case, your team creates a branch before release time to stabilize the release and then merges changes from the release branch back into the main source tree after the software is released.