[haiku-development] Re: Request for vote for next release naming
- From: sean collins <smc.collins@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 11 Feb 2014 08:49:15 -0500
sorry for the top post. damn phone doesnt seem capable of properly editing
email.
as i said. r1 isnt the end of haiku. you can always have r1.1 1.2 etc. each of
those new release can add new features and subfeatures improvements etc. system
upgrades. apl server enhancements. fully functional imap.
haiku is stuck in beta hell. its time to go forward akd someone needs to step
up and lead and get this baby delivered
as ro fixing embarssing flaws. i geuss its time ti start ide tifiying and
triagin those issues. the bigger issue is the loss of momentumn in the project
Sent from my Samsung Galaxy Note® II
<div>-------- Original message --------</div><div>From: Ingo Weinhold
<ingo_weinhold@xxxxxx> </div><div>Date:02/11/2014 7:45 AM (GMT-05:00)
</div><div>To: haiku-development@xxxxxxxxxxxxx </div><div>Subject:
[haiku-development] Re: Request for vote for next release naming </div><div>
</div>On 02/11/2014 12:47 PM, Axel Dörfler wrote:
>> 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 :-)
See, there's your mistake. ;-)
> 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.
If you compare them like this, I think I haven't brought my main point
across. IMO the betas should be significantly different from the alphas.
We did the alphas to show off our progress and give people a (somewhat)
stabilized version to work with. They could (and did) stand on their own
and lasted a rather long time (well, too long really).
IMO the betas should be relatively frequent (say monthly or at most
bimonthly) snapshots on the way to the final release. Save for the first
beta we should not (have to) spend time on polishing the release, since
by restricting ourselves to bug fixes the likelihood of regressions
should be relatively small.
The beta 2+ releases generally wouldn't even have their own tickets; the
tickets would belong to R1 final. As long as there are still R1 final
blockers, we'd continue to release betas. Once all blockers have been
fixed or demoted, we'd push out a RC.
That being said, you're right, of course, that there are different
legitimate approaches. I'm just proposing mine as an aggressive way to
get a final R1 out quickly.
CU, Ingo
Other related posts:
