Hi,
On Sat, Sep 23, 2017 at 9:53 AM, Adrien Destugues
<pulkomandy@xxxxxxxxxxxxx> wrote:
Hi there,
On the existing Haiku-managed repo
==================================
The existing repo at download.haiku-os.org is used when building Haiku
from sources. This is where we download package files from. It is
managed using jamfiles in Haiku sources and the "upload-packages" jam
target.
It was set up this way because it automatically keeps an archive of old
repo states, allowing people to build Haiku from old sources and get a
working image (useful for binary searching regressions, for example).
The new repo does not provide anything like that, it is more of a
rolling release with only a "current" branch.
My suggestion here is to keep things as they are, but:
- Strip the repo used to build Haiku to strictly the things needed to
build Haiku. This means it remains used at build time, and we still
need to manually upload packages to it, but much less often as it is
only for the core libraries.
- Make the images point to the eu.hpkg repo by default. This means on
first install, people will have a lot of updates to install already,
but then they can easily keep their system up to date.
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.
It depends on what the plans are for R2. I don't think there is much
code breaking binary compatibility in the works yet, so maybe the delay
creates no problems and we can continue with a single branch for some
time? In that case the beta1 branch would follow the same lifecycle as
previous release branches: a few weeks/months of stabilization, then the
branch "dies" when the release is made.
