stable vs. unstable trees

[Shachar Shemesh]

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