It's all about context: how often do you release and what is in a release.
Here's a bit of a case study that I had with my old work, using the B method (we called it branch by purpose).
To put the story in context,
- A release consisted in new features in our software: new gaming modes, new functionalities, new configuration options.
- The release cycle was fairly long: our clients were universities that would stick with one feature set for usually a year.
Main development was made into the trunk until we reached a feature-complete state for a certain release. At that point, we would create a branch, say projectname-january2012 and do our quality testing and bug fixes in that very branch. Once we were ready for a public release, we would tag the code in that branch, and release.
However, development on the release did not end at that tag. Inevitably, we had clients that found bugs or small issues with the release. So in that case, all we need to do is to go back to that branch, patch the code and create a new tagged version of the january2012 branch to be released, and merge the fixes back to the trunk.
In our case, this approach was favorable because some users preferred to stay with older releases with a limited set of features, or simply because the cost of deploying on their infrastructure a whole new version rather than a hotfix caused some issues.
So the questions you have to ask yourself are:
- How often do I release?
- Are my releases going to be 100% backward compatible?
- Will my clients be ok with completely upgrading to fix bugs?
If you release often, then maybe it's not worth it to have branches for each of them. However, if your release cycle is fairly long like my old use case, and that deployment, backwards compatibility and clients clinging to old releases might be risks, option B will certainly save you a lot of pain, will make things a lot easier to support your clients at the minimal cost of dealing with branch clutter.