Version Control: developing on branches rather than master/trunk

I’ve changed my mind.  It now seems that it is much more sensible to develop on branches rather than on master or trunk.  What am I on about?

Well software source control or version control systems.  I tend to use two: subversion and git.  Actually, I tend to use git whenever I can including when I have to use subversion. git svn is, in US terms, awesum.  One debate I have had on and off is whether to:

• Do development on trunk and put releases in branches — OR
• Do development on branches, merge to trunk, and tag releases (or put them in their own branches).

I’ve previously done the former, but I’m rapidly shifting to the latter.  My rather simple reasoning is that I want trunk/master to be, to all intents and purposes, a working copy of the latest software.  i.e. the software that is in trunk/master passes its tests, builds and basically does what it says it should on the tin.  The developing software is done on a branch and only merged back to trunk/master when it passes its tests.  Thus the process is:

1. Branch
2. Develop & test
3. Merge from trunk/master to the branch (i.e. pull any updates)
4. Test, test, test
5. Review code with buddy, senior dev, etc. (depending on your set-up)
6. Merge back into trunk as a finished feature.

Even better, only work on code that is actually described in a ticket, bug, or on something like pivotal.  That way you stay focussed and only spend time on developing features/fixing bugs that the ‘customer’ actually wants.

The only question then is what you do with releases?  My initial guess is to tag them as a release on trunk/master.   Then if you get a bug and have to maintain the old release then to branch at that point and maintain the release as its own ‘master’ release branch.