[haiku-development] Re: Beta1 release roadmap (again)

  • From: Niels Sascha Reedijk <niels.reedijk@xxxxxxxxx>
  • To: Haiku Development <haiku-development@xxxxxxxxxxxxx>
  • Date: Mon, 25 Sep 2017 22:09:00 +0200

Hi,

On Sat, Sep 23, 2017 at 4:28 PM, kallisti5 <kallisti5@xxxxxxxxxxx> wrote:

On 2017-09-23 02:53, Adrien Destugues wrote:


Packages and R1 branch
======================

The current plan for beta1 is that it is the branching point for the R1
branch. This means, once beta1 is out, there will be two live branches
in the Haiku repo. The R1 branch with the goal of fixing bugs in beta1
(no new features), and the master branch where works towards R2 could
start.

Doing things this way means the master branch will start to break binary
compatibility at some point. This means we need a different set of
packages and packages builders for it.

Our options are:

- Set up haikuports & buildmaster to handle this and publish two
  separate repos. We may need to extend haikuporter to be able to tag
  recipes as "R1 only" or "R2 only", I guess. It should be possible to
  use the haiku version for that (haiku >= R1~beta1 or haiku >= R2 or
  so).
- Give up on creating the R1 branch now and delay that to beta2. This
  allows us to get the beta1 release sooner and work on these
  infrastructure things a little later.


I think having the R1 branch to "roll" all the betas towards R1 final is
pretty much a requirement.

Pros:
  * It gives us tons of time to stabilize more.
  * We have a complex ecosystem, lots of time to "finish things up"
  * If beta1 and beyond will "turn-into" R1 via updates, then people
    are more likely to use the release. (and in-turn, test it more)
Cons:
  * We have to be diligent. This would mean master and R1 would diverge
    and have to be groomed in the long-term. If we delay R1 releases for
    4 more years... that's 4 years of grooming someone has to do.

I think this is a particular important point. IMO we are thin on
developers right now, and if we want to get R1 out of the door, I
think we need to focus every bit of developer attention to make the R1
magic happen. If it were up to me, I'd say we agree to a release
schedule that targets next year.

So:
* R1 beta 1 for Christmas (release in December).
* R1 beta 2 for Easter (release in March)
* And R1 just in time before summer break.

After beta 2 the focus will be solely on bug-fixing, so that will be a
good moment to branch off R1 and to open up master for R1.X or R2.
(Personally I'd even say that nobody gets to play around before R1 is
out, but I know that that's a very unpopular position).

My suggestion would be to form an R1 release committee that will
coordinate the development work and the infrastructure work in order
to make the release happen. Through regular meetings in which the
action points can be fleshed out and delegated, they can keep the
release going. This might go agains the way we have been organized
previously, but the promise of this structured way of working is that
next year summer we can pop open the champagne.

Regards,

N>

Other related posts: