[haiku-development] Re: [haiku] Re: Future releases? Recommend nightlies? gcc2?
- From: Adrien Destugues <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 1 Dec 2016 23:18:33 +0100
On Thu, Dec 01, 2016 at 03:22:10PM -0600, kallisti5 wrote:
I plan to maintain the gcc2 support in the branch created for beta1,
with releases from that branch from time to time until it reaches R1.
That would leave the trunk free for a gcc5-only version, first steps
towards R2.
So wait, we're saying...
* Branch R1 *soon* and make a R1B1 beta release gcc2h
* PulkoMandy (and others) will cherry-pick bug fixes to R1 branch.
* Master is now targets R2
My only worry is R1 will get really outdated, we won't get a release out,
and we'll have to fold the R1 branch back into master (or toss it)
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.
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.
I guess that makes sense, we can then use the "stable R1" branch in future
hybrid concoctions of R2 with gcc2 secondary.
For R2 I would go 64bit only. Make the R1 ABI stable on x86-64, and have
R2 include a compatibility with that. This way, people can continue to
use R1 apps with R2 (but they can't use BeOS R5 apps anymore).
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.
--
Adrien.
Other related posts:
