[haiku-development] Re: Beta1 and R1 release plan
- From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 03 Nov 2014 14:34:56 +0100
Am 03.11.2014 12:00, schrieb Adrien Destugues:
The R2 side of things was left open to discussion on purpose. I know
there isn't much agreement (or even much discussion) on what R2 should
be. I would prefer R2 to happen in less than 13 years, as maintaining
the R1 branch for so long is not something very enjoyable.
The best way to achieve this, though, is to actually fledge out a plan :-)
The way I see things, is that our master branch is a playground for
developers. That doesn't mean R2 is. An R2 branch can be split out of
the master and stable features merged there. We can then plan a release
at any time knowing that we have a stable branch to work from. Starting
the R2 work from the R1 branch instead would mean more work in catching
up with trunk and I'm not sure what the gains are.
Maybe I did not made myself clear enough: without keeping those branches
connected, as a user, you won't have any functional update of Haiku for
the years to come, as you likely would not want to live on the bleeding
playground edge.
Before making master a playground, I would prefer a Linux like approach,
ie. a next (playground), and a stable repository, and establish a review
process for the latter only (IIRC Oliver is still investigating this).
Still, even playground should only receive mostly complete features.
That other playground should stay the local/github repository of the
developers.
As far as I'm concerned, source compatibility would be enough.
For me, this would not be acceptable at all (as I said, not necessarily
R1, but in the long run). While you position yourself clearly, I'd
rather like to see a discussion of why source compatibility would be
enough. Are there any objections to the notion that 1) one repository to
rule them all is impossible, and that 2) not having binary compatibility
sucks as soon as you have more than one repository?
Source compatibility is, to a certain degree, nice, but doesn't help a
thing. With this.
While at first the master branch may see a lot of disrupting changes, at
some point it will have to get into a more stable state and start
pushing out alphas, betas and stable releases. The availability of
alphas and betas means 3rd-party devs can test their apps there, fix
them if needed, and get them up to date and ready when the final R2 gets
out.
We see how well that works in the Linux world. Or at Mac OS X which has
seen at least a number of compatibility issues in the past.
I agree that an R1 compatibility layer (source or binary) in R2 would be
nice, but it needs someone to maintain it. If no one has enough interest
in it to actually make it happen, I don't think that should lock the R2
release forever.
Sure, but otherwise you will make R1 a dead end. I'm not sure how I can
express this more drastically: Haiku would be pretty much dead until R2
is ready.
I honestly don't think it will be that much work either; we already have
all the needed stuff in our current repository. We would just need to
put this (ie. the kits, libroot + ffmpeg add-on) into a separate
directory, and adjust the build to be able to build a GCC2 version from
that, otherwise it could be ignored. It would be nice to share the
server protocol headers, or at least parts of it, to make maintaining
those simpler. All applications, servers, etc. would remain where they
are now, and would only be built using GCC4 from R1 on.
We would still be in a position to deliver actual OS updates this way
for the years to come (disregarding GCC4 compatibility).
There is a playground, which is the master branch, and there are
releases. Currently R1 is supposed to be derived from trunk state, which
means developers are not willing to introduce any changes there in order
to not break things. We have a problem here which dates back to our SVN
days and our signle-branch git workflow.
You have github and friends now. All we need is a place for bringing it
all together before moving it to master. That could also be a
development branch in the main repository.
And while another workflow is all nice and good, it's also more work for
some people which actually have to do that work in order to go forward.
It's not like it comes for free either.
IMO only if we decide not to have the manpower to do that, having master
be a playground is desperate, but the way to go. I'd like to try that
first to know for sure, though :)
By putting beta1/R1 in a branch, the idea is to free the master branch
of those constraints. It is not to free R2 of those constraints.
Sure, that one should end up in a branch. But as you know, it *is*
plenty of work to keep it up to date. You shouldn't be the only one to
do that work, or you'll be burned out in a few months.
To sum it up:
- Beta1 and R1 are made from the same branch, with a feature freeze and
only bugfixes from one to the other
We agree on that much :-)
- R1.1 and subsequent releases (if needed) are made from that same
branch, with more bugfixes, and possibly with a timed schedule (every
3, 6 or 12 months for example) - or as rolling updates to the
repositories. There may be a limited set of new features here but with
very very careful review to avoid any regressions.
- R2 can be branched either from the R1 branch, or from trunk at some
later point. This one can integrate more new features and other
breaking changes. There probably needs to be an alpha/beta phase for
it. Some kind of compatibility with R1 could be included.
Following my suggestion, this would look like this:
- After R1 is released, we switch master to move GCC2 support to a
legacy folder. Once that is done, it will be merged into the R1 branch,
too (IOW, this branch (or one based on it) would become our release
branch also for future releases). This will also make merging changes a
lot easier.
- R2 would happen in the GCC4 part of our tree. All applications &
servers that come with Haiku would be switched to GCC4 (again, this
would affect the release branch, too).
- This way, we could deliver frequent updates to Haiku without having to
worry about binary compatibility too much for quite some time to come.
That would also mean that we will break binary compatibility for
Tracker/Deskbar add-ons, etc. - I think this is acceptable, but if
someone finds the motivation, I'm sure this would be fixable, too.
The actual R2 release would mark the date when we make our GCC4 (or
clang, for that matter) API stable. At that point we could decide (or
not) to officially drop support for the GCC2 compatibility layer (ie.
make it a nice-to-have external package that would not hold up future
releases).
Also, our libraries will then get versioned like any other, and we may
need to keep old ones around for binary compatibility.
Bye,
Axel.
Other related posts:
