The way I see it, you decide on a FEATURE freeze. Then you cut the stable branch. Next, you start stabilizing that branch for release, not allowing commits into that branch of new features. Once it is released, you merge the changes there into the development tree, and perform a new feature freeze for a new version. The fact that 0.9, 1.0 or 3.1415 are still a long way away is insignificant, as far as I can see it.
So, we decide that (for example) BiDi support will not be for 0.9, so all BiDi related changes are commited to the dev branch, and so on.
The problem with this model of working, as far as I understand it, is that WINE has little changes that are new features per sa, and most changes are simply a result of changes to existing infrastructure (after all, in a way, we are only following someone else's lead, not making up our own APIs).
It may still be possible to adopt this model, however. Seperate bugfixes from enhancments, and direct them at different branches. It may be a good idea (following the guitar thread) to define a set of apps that should be supported as "features", and make the above suggested distinction between what should go where based on that.
It is my experience, however, that unless someone steps up and say "We need to stop merging new stuff", the version never reaches release quality. Linux 2.4 and Debian Woody/Sid are two points to consider in this regard.
Shachar