Question: In large Libre Source software projects, versioned with Mercurial or similar DVCS tools, which of the following is considered to be more conventional:

1. Keeping the latest "stable" version of the software in the `default` branch. Tagging each release in `default` so you know which revision got packaged up as a download. Merging patches into `default` as soon as they are tested. Keeping new features, etc. in named branches to be merged into `default` on the next release.
2. Keeping each release in a named branch, or similar. Using `default` to keep bleeding-edge code that's only intended to be run by developers or the very foolhardy.

Or... is there some better pattern of workflow that it widely accepted?

Answer: 
Mercurial has a fairly strong opinion on what you should use your `default` branch for. It's documented in the [Standard Branching wiki page](http://mercurial.selenic.com/wiki/StandardBranching). The summary is:

* You should not use a name other than `default` for your main development branch.

The reason is that `default` is the branch that is checked out by new clones. If you try to use some other name for your "main" branch, users will get a more or less random branch when they clone and commit things in the wrong place, which is generally undesirable.

Even with tons of documentation that says "branch before adding a new feature" (see next point), people will forget this when they send you patches. They then have the trouble of cleaning up things by moving changesets around.

So always put the bleeding-edge code in the `default` branch and use other branches for your stable releases.
* Don't treat branch names as disposable

Branch names are a permanent part of each commit and allow identifying on which branch each commit was introduced. Thus you will want to give some thought to your branch names so that you don't pollute the branch namespace.

Also, if you attempt to use a branch per bugfix, you may eventually run into performance issues. Mercurial and the tools surrounding it are designed to work well with hundreds of branches. Mercurial itself still works quite well with ten thousand branches, but some commands might show noticeable overhead which you will only see after your workflow alredy stabilized.

We have caches in place internally in Mercurial, so the problems are mostly UI problems: hosting sites and log viewers might run `hg branches` to load all 10,000 branches into a single drop-down menu. That is really slow and useless for the poor user that want to select a single branch from the gigantic menu.

If the branches are closed, then they wont show up in `hg branches`, and so the problem should be minimized. However, the tools might want to show closed branches too — it all depends on the tool.

I'm sorry this is a little vague. The main point is that Mercurial is built to scale in the number of *changesets*, not the number of named branches. We have addressed the biggest performance problems with named branches with the cache I mentioned before, so today I'm not too concerned about having many branches, especially if the number of open branches is kept small (less than, say, 100).
There's not a huge amount in it. If we're talking about just DEV & STABLE branches, which is default is mainly just a naming convention. I'd tend to have DEV as default, just because most work goes happens on the dev branch and if this is the default branch, it's less hassel.

Personally I prefer a named branch per release. Bugfixes can then go on those branches and be forward ported with relative ease to all releases after using `hg merge`. If you try to do the same with DEV and STABLE, you can only ever have one maintained release (the last one), or your stable branch starts growing branches and you end up with a (possibly less organised) version of the branch per release structure.