On February 11, 2014 at 11:04 AM Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
I think it is important to a have a phase where only bugs are addressed.
If that isn't the beta phase, then a gamma phase is needed. Though, I
don't really see why it shouldn't be the beta phase in the first place.
I almost agreed with you, but then rethought :-)
I see two different approaches here:
a) we start a release branch once we can agree that we've implemented all
features needed for the release.
- that branch may only ever receive bug fixes.
- once we're somewhat happy with the branch, we release a beta to give it more
audience and wide-spread testing.
- If there were many new bugs, we may want to do another release to uncover them
before going serious.
- eventually, we reach a point where we release a RC from that branch (and later
R1).
b) we start a release branch once we can agree that we've implemented all
features needed for the release.
- initially, we're aiming for beta, and while we want mostly bug fixes, we may
also agree to accept smaller or self contained new features.
- once we're somewhat happy with the branch, we enter release mode for it, and
only accept bug fixes. Once all release blockers have been fixed, we do the beta
release
- we then decide, if we want another beta phase, or will now aim for the release
candidate.
- in the former case, we just repeat the strategy above, in the latter case, we
go into bug fixing only mode.
- eventually, we reach a point where we release a RC from that branch (and later
R1).
I think both approaches are legitimate ways to develop a software. In your
suggested approach (a), the only difference between the "beta" and "release
candidate" phases is the number of known bugs. In the alternative, the beta
phase might also introduce new features, while the RC phase doesn't.
There would still be a phase to stabilize the beta further in (b), it just
likely wouldn't see another release before the RC.
