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.