[haiku-development] Beta1 and R1 release plan
- From: Adrien Destugues <pulkomandy@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 2 Nov 2014 10:22:57 +0100
Hello devs,
During the BeGeistert coding sprint we had a long discussion with Ingo,
Oliver and Ithamar about the future of Haiku and the problems we have
with getting releases out. We have reached an agreement on this and we
would like to propose a plan to finally get R1 out and move on to the next
steps of development.
The goals here are multiple:
* Finally provide a stable release which third-party developers can use
* Setup a better release cycle so we can put out releases more frequently
* Let the developers work on more exciting things without making them
feel guilty for not working on the important R1 stuff
Our reasoning is that there is now little interest for R5 binary
compatibility for some of the developers, and possibly also amongst the
users. We know a lot of people use more Qt and Java applications than
R5 ones, and over the last two years the HaikuArchives team has been
busy recovering the source for some BeOS applications so they can be
updated for future Haiku releases. Moreover, we believe that a stable
R1 release will help getting 3rd party developers interested into
Haiku and bring new apps to fill the gaps where compatibility is
lacking.
We have drafted a plan to allow for a smooth transition to the future
Haiku.
This includes the release of Beta1, and from then on moves on to a
stable R1 with a maintenance branch, and development on R2 and other
fun stuff happening in our git master branch as it always did.
Requirements for Beta1
======================
At this point we have reached the "feature complete" mark as defined
by the 2010 "future haiku features" poll. The last big thing missing
was the package management support, which has been merged in Haiku one
year ago and is now stable and usable.
There are, however, some blocking issues left that prevent getting
Beta1 out of the door. Most of these are not development tasks for
Haiku itself, and relate to the PM infrastructure. We need an
automated way to build packages from Haikuports recipes in order to
distribute them with the release. The current practice of getting a
developer with commit access to upload packages is not acceptable
because it is too much work and leads to problems keeping all packages
working (a package is updated because it is a dependency for another
one, but that breaks a third one which can only work with an older
version, etc).
There are also a few open questions such as the lack of IMAP support
in current releases. This has been missing since Alpha3 and there are
acceptable alternatives (using Beam or webmail), so the IMAP support
could be left out.
Plan for Beta1
==============
Without the issues above fixed there is no point in trying to get a
release out yet. So let's first get that to happen. Oliver has been
working on getting this in place but more help would be welcome. This
involves work on HaikuPorter (Python), as well as the server
infrastructure to run the builds. It may be a good time for non-C++
developers to join the project.
After these issues are solved, it will be time for a release. I am now
stepping up as a release coordinator for this. My plan is to use more
or less the same scheme as for the alpha releases and get Beta 1 out.
Plans for R1
============
I have been requesting that we set up a plan for R1 and beyond instead
of planning for just a one-shot alpha release every year. Here is my
proposal for this.
Starting from the Beta1 release, the trunk of Haiku will be dedicated
to work on R2. The exact contents of that new release is to be decided
between developers, but there is an agreement towards switching to
gcc4 or clang as the main compiler, getting rid of our old hacked libc
and replace it with some mainstream one, and some API cruft cleanup.
C++11 will also start to be used more.
Support for R1-API and/or BeOS R5/gcc2 compatibility in R2 may be
maintained if someones steps up to do this - none of us BeGeistert code
sprinters have interest in doing so, but other developers may want it.
It may not even need to stay inside the Haiku source tree, and we could
provide it as a 3rd-party library - similar to how our Qt port is built
currently. There is some effort in getting this done so people must step
up to take care of it.
Meanwhile, the Beta1 branch lives on as what will eventually become
R1. Then plan here is to listen for users and developers bugreports
and backport fixes from the master branch as needed. Since Beta1 is
feature complete, no new feature ever gets added to that branch. As
the release coordinator for Beta1, I can also take the role of R1
maintainer and take care of the backporting. After a reasonable delay
(maybe 3 to 6 months - depends how much bugs get found) after the
Beta1 release, an R1 version will be built from the same branch. From
there on the branch can live on and have point releases (R1.1, etc) if
new issues are found. Or, it can be switched to a "rolling release"
mode where updates are pushed using the package management. No new
features are added in this branch.
We think this plan allows for a relatively painless and short-term R1
release. As Haiku developers, we have to admit that it will not be a
perfect release. It will be more polished than the alphas thanks to
the beta testing and reuse of the same branch used for Beta1, but it
will have known bugs and limitations. I don't think there is a way to
get a perfect and bug-free release in a reasonable timeframe with our
current manpower.
Following the R1 release, the BeOS R5 compatibility can continue to
exist in the R2 branch, either in-tree or as an external package.
The R1 branch continues to get fixes so people using Haiku in production
(we're thinking of TuneTracker here) can rely on a rock stable and
supported version to base their products on. This way, people can
continue using the stable R1, or migrate to R2 and enjoy all the new
features, but risk discovering new bugs.
--
Adrien.
Other related posts:
