Releases or features: how should branching be done in source control?

So at SlideShare we currently organize our source control branches by release. This works our pretty well (we can work on something that’s a month or two away from being ready, without messing up our ability to deploy other stuff next week).
But one thing I don’t like about this model is that it’s a little inflexible. If one feature on a release is taking more time than was planned, it’s hard (impossible?) to “unbundle” it from the other features and deploy a fraction of a release. In other words, removing a feature from a release is not straightforward.
I’ve heard some shops organized their source control by feature. This seems interesting (it removes the problem I’ve described above) but a little tricky (what’s a “feature”? Does every bug fix have it’s own branch? Seems to bring a lot of subjectivity into the system). Since their are probably several features in a release, this also greatly increases the amount of merging that has to happen to do a release.
Thoughts? Reactions? How are the branches organized in YOUR source control system?
UPDATE: The LinkedIn “Answers” feature rocks! Check out all the thoughtful replies to this question here.