[haiku-development] Re: Proposal from Begeistert: Getting Ready for the First Beta

  • From: Jessica Hamilton <jessica.l.hamilton@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Mon, 16 Sep 2013 03:12:12 +1200

On 16 September 2013 02:49, Niels Sascha Reedijk <niels.reedijk@xxxxxxxxx>wrote:

> Hello all,
> In this message I would like to forward a proposal that came out of an
> interesting group discussion at BeGeistert. I would suggest everyone to
> look at it. If you have any comments, feel free to post them. If necessary
> we can put it up for a vote.
> Considering the fact that Package Management is one of the corner stones
> of our R1 Roadmap, and the fact that package management will be merged in
> the coming week, we propose the following:
> * We will aim for a release of the first beta of Haiku in the next 2-3
> months.
> * The release will be made from a branch. The branch point will be 6 weeks
> from now.
> * We will take 2-4 weeks to test the hell out of the beta branch.
> * A release-manager will be responsible for taking care of the beta branch
> * The branch will be the basis for future regular (beta) releases
> With the schedule above we are aiming for a fast way to show of the
> wonderful work that has gotten into Haiku since alpha 4. We also open up
> the opportunities for end-users to start testing and delivering feedback in
> order to get us to the goal of releasing R1.

A fast way doesn't need to be a beta, and rushing rarely produces quality.
And if package management lives up to its name, surely it will be easier to
go from a fifth alpha into a beta.

I would prefer to see a focus on robustness, not speed. Rushing into beta
will in my opinion be worse than the release of alpha 4 which immediately
required a point release.

If there's one thing I've noticed people actually want, it's a better way
to update their system. Does package management yet solve this? If not,
moving to beta is definitely unsound. If it does, then surely it wouldn't
hurt to stick with one final alpha which introduces breaking changes before
migrating to beta, since improved/actual support for rolling releases
should be possible.

Other related posts: