Releases with multiple long lived branches using maven

I wouldn't recommend a qa and prod branch. Read up on subversion best practices. I'd recommend The SVN Book, in particular chapter 4 regarding branching/merging.

You should version every release even if it is to QA (through tags). Trunk is used for current development work, tags are for released versions(defined as "feature complete", not what environment it is in), and branches are for defect fixes (amongst other things).

Sample Scenario:

Version 1.0 is in production, your team has just released 2.0 to QA for testing, and are now working on a 3.0 release. At this point you would have:

• /trunk (developers working on 3.0)
• /tags/2.0 (used for QA)
• /tags/1.0 (historical for what is in production)

If your QA team finds a problem in 2.0, you'll create a branch off of the 2.0 tag. Make your fix, merge to trunk then release the branch as 2.0.1 (another tag). You would then be left with:

• /trunk (developers working on 3.0, + the 2.0 defect fix)
• /branches/2.0.* (use the * character to indicate this is where all 2.0.* fixes will be committed. You can reuse this same branch if yet another defect is found in the 2.0 code)
• /tags/2.0 (original tag QA was testing with the defect)
• /tags/2.0.1 (2.0 code base, with ONLY the defect fix)
• /tags/1.0 (historical for what is in production)

I've done some similar work around branching and releasing before, and in my experience, the setup you have described has ended up becoming very unwieldy and bureaucratic before too long.

Domenic D.'s answer is pretty close to the sort of set up I would prefer, particularly with a small number of developers.The more branches you have, the more complex the management of the code base becomes and the more likely you are to introduce error through bad merging practices.

One thing you don't mention that is important, in my opinion, to get right at the start is your check-in policy. The SCM is not a backup for incomplete work, you should strive to make sure the main lines are at the very least always building. Be strict about this, it will make everybody's life easier in the end.

The main thing is though, no matter what release procedures you come up, make sure you get buy in from your team and that they don't have to be "forced" into place. That is a sign that there may be something wrong with what you've come up with is not right and will probably be quickly ignored or subverted.