Say that we've decided on following a "release-based" branching strategy, so we'll have a branch for each release, and we can add maintenance updates as sub-branches from those.

Does it matter whether we:

1. develop and stabilize a new release in the trunk and then "save" that state in a new release branch; or
2. first create that release branch and only merge into the trunk when the branch is stable?

I find the former to be easier to deal with (less merging necessary), especially when we don't develop on multiple upcoming releases at the same time. Under normal circumstances we would all be working on the trunk, and only work on released branches if there are bugs to fix.

What is the trunk actually used for in the latter approach? It seems to be almost obsolete, because I could create a future release branch based on the most recent released branch rather than from the trunk.

Details based on comment below:

• Our product consists of a base platform and a number of modules on top; each is developed and even distributed separately from each other.
• Most team members work on several of these areas, so there's partial overlap between people.
• We generally work only on 1 future release and not at all on existing releases. One or two might work on a bugfix for an existing release for short periods of time.
• Our work isn't compiled and it's a mix of Unix shell scripts, XML configuration files, SQL packages, and more -- so there's no way to have push-button builds that can be tested. That's done manually, which is a bit laborious.
• A release cycle is typically half a year or more for the base platform; often 1 month for the modules.