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
To move forward from the discussion we've been having about supporting a
particular list of applications, I'd like to propose that we have a
stable and an unstable wine tree.
In this way, we can have new patches from developers go into the
unstable tree, and once a release has been tested for
I think that was the plan. But I'm not sure this makes sense until we
reach 1.0
/Ulrich
On Fri, 2002-03-22 at 13:20, Michael Cardenas wrote:
To move forward from the discussion we've been having about supporting a
particular list of applications, I'd like to propose that we have a
stable
Ulrich Czekalla wrote:
I think that was the plan. But I'm not sure this makes sense until we
reach 1.0
/Ulrich
On Fri, 2002-03-22 at 13:20, Michael Cardenas wrote:
To move forward from the discussion we've been having about supporting a
particular list of applications, I'd like to propose
The problem is what criteria do you use to declare a stable branch. You
can't just arbitrarily start a stable branch. Stable branches are cut
from releases. That is why we can say they are stable. Since our first
release won't be until 1.0 we should probably wait until then.
/Ulrich
On Fri,
Having more regression testing of applications will help us get to 0.9.
If user's can't test one day becasue they can't compile, that means
less testing. It also means we might lose that user as a tester all
together.
Very true. I'm still running 20010510 because newer ones don't run
[EMAIL PROTECTED] wrote:
Having more regression testing of applications will help us get to 0.9.
If user's can't test one day becasue they can't compile, that means
less testing. It also means we might lose that user as a tester all
together.
Very true. I'm still running 20010510 because
