[haiku-development] Re: Pushing for R1 (Final)
- From: Adrien Destugues <pulkomandy@xxxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 15 Nov 2010 23:10:23 +0100
Le 15/11/2010 22:36, Clemens Zeidler a écrit :
Hi,
I'm not really in the release and marketing process so just take it as
my opinion. Prove me wrong but I think we already reached the goal of
R1 to create a replacement of BeOS R5. In most places Haiku is much
better / more modern than BeOS ever has been. I think Haiku is feature
complete and we should enter the beta phase to make a cut. Thinks like
a package management are very important and I really like to see them
soon but I think its more important to have an earlier R1 release. We
can put this additional features in a next release, maybe R1.5. I
would estimate that waiting for all this want to have features takes
at least another year.
I think it's important to show the outside world that we reached the
status of R5. To be in the official state of still replacing a 10 year
old OS is not the best position to attract new developer with new
ideas. And we are beyond this point!
Somewhat true.
But this means we should have a plan for R2.
I'm a bit worried of what will happen after R1. There are pretty clear
plans as to what R1 should (and should not) be, but there's nothing
after that. How are we going to change the gcc4 API to a new one, for
example ? Which feature will be added ? Will we change the look of the
tracker and deskbar ?
On one hand, we release an R1 with a 10-year old API and compiler for
3rd-party apps, no one is going to use this, really. So we will see gcc4
apps coming around once R1 is released. Then we will breakcompatibility
with all these apps in R2 (or somewhere in between R1 and R2), and apps
developper will have to maintain 2 versions of their binaries.
On the other hand, after R1 it looks like we are going for another
10-year development cycle, with a lot of planned features and things to
do. For example, we are going to phase out the unuseable outline list
view and introduce a new, cleaner API. How are we going to do that ?
Will we keep the old one for compatibility, or update all parts of Haiku
and remove it ? How will the release cycle be ? Are we going to make a
new version every 6 month ? 2 years ? more than that ?
Answering some of this questions also tell us which level of quality we
should have for R1. If we expect R2 to be released 1 or 2 years after
it, then R1 can be somewhat unpolished, as there will be a newer version
to replace it soon enough. If, on the other hand, we chose to set a big
objective for R2, with a longer development cycle, then R1 should be as
polished as possible, so people will stay using it instead of wanting to
try the latest alphas. This, of course, must be balanced by the fact
that we can't postpone R1 forever.
--
Adrien.
Other related posts:
