23 Sep
2010
23 Sep
'10
10:40 a.m.
From: gedmurphy(a)gmail.com
To: ros-dev(a)reactos.org
Date: Thu, 23 Sep 2010 08:09:57 +0100
Subject: Re: [ros-dev] 0.3.12 milestones status
victor Martinez wrote:
I am not agree :) As far as i see we have tried to (more or less)stabilize trunk before
branching at least in the 2 latest releases. An i.e is the 0.3.12 release, if we are
following the "bleeding edge" concept then we should have branched several
months ago and just pulled the regression fixes from trunk to the branch. Our approach was
different: Stabilizing trunk fixing the known regressions (which,btw,were marked as
Milestones) and then branching.
There is not an incompatibility with the "stabilizing trunk" and
"branching" concepts. First because exists the "Hack-releases" (fixes
just applied for the release) and that just can be done in a branch. Second because a
(more or less) stabilized trunk doesn't mean a regression-free trunk (but it could
be).
The first main advantage (about avoid sending critical code in the month we are going to
release) is that we will have a whole month to check if the critical changes has waken up
underlying bugs (or if the critical changes has introduced Eisenbugs).If we are following
the "bleeding edge" approach we can just pray to find those Eisenbugs in the
Release Candidate ISO tests and, since there aren't a lot of testers checking the RC
ISO, it is quite unprovable.
The second main advantage is that we reduce the Release Engineers amount of work. It is
not the same bugging them to create just one RC ISO than bugging them to create 2 or 3
because playing with the "bleeding edge" concept.
In the same way, and imho, I think it is much
better
to avoid sending critical code one month before the release.
This isn't how you release.
The whole point in branching for a release is so you can stabalise the
branch whilst trunk continues to be 'bleeding edge'
What's the point in branching otherwise? We may as well just tag trunk and
do away with branching.