[haiku-development] Re: [haiku] Re: Future releases? Recommend nightlies? gcc2?
- From: waddlesplash <waddlesplash@xxxxxxxxx>
- To: Haiku Development ML <haiku-development@xxxxxxxxxxxxx>
- Date: Thu, 1 Dec 2016 20:24:53 -0500
On Thu, Dec 1, 2016 at 5:18 PM, Adrien Destugues
<pulkomandy@xxxxxxxxxxxxx> wrote:
My main worry is people will get crazy with new features in the R2
branch, and it will get all broken with half finished work in it.
Yes, this exactly. We *NEED* an R2 game-plan before we start doing Big
Things (TM).
From the R1 branch, we can make release easily because it is a stable
branch and we don't merge things as easily as in trunk. So whenever
people say "we need a release", we can make one.
It may end up stuck in an endless list of beta and never an R1, but that
doesn't matter. We can do one last release from that branch when we
abandon it and call that R1. Then we create a new branch and do R2b1 or
R2a1 from there and start a new cycle.
Abandoning the R1 branch is my biggest fear, as I have said again and
again. I posit that very few people care about BeOS binary
compatibility these days, so, here's a radical idea: Why don't we go
through *all* of the tickets in the R1 milestone, figure out which
bugs we actually "must-fix" before R1 is released, and then throw all
the rest into unscheduled?
I think having each release compatible with release N-1 is good enough,
especially as we don't release very often. Of course, if someone plans
to maintain gcc2 compatibility in the R2 branch, why not. But that won't
be me.
My personal feeling is that we should just nuke compatibility
altogether with R2, and do the major refactoring/cleanups that we've
wanted to do for so long, but can't because GCC2 (e.g. upgrade
glibc/switch to musl, use C++11 everywhere, redo error handling setup,
etc. etc.) as well as future-proofing so that we *don't* have to do
something that radical for a while (new Replicant API? etc.)
If we really want to keep GCC5 ABI compat between R1/R2, that should
probably go in a separate repository + HaikuPorts package, rather than
keeping duplicate code or whatever in trunk.
-waddlesplash
Other related posts:
