So, it seems that we are going to have a Beta6 release shortly..
But, when will this be considered as “Released’?
Is there any certifying body that will approve this as ‘Released”?
What are the minimum requirements to consider Haiku R1 as “Released”?
There have been many discussions in the past what R1 should be.
Nobody knows exactly when it’s ready and how many features still need to be added,the initial goal of having a perfect BeOS replacement is already achieved and Haiku can do more than BeOS ever did.
To make things short: It’s ready when it’s ready.
Some past discussions about that:
Working Webcams and NVidia accelerated 3D Support for Beta6 would be huge
Some topics appear regularly every few months.
Pin a dedicated thread for these items, so that forum newcomers can be more aware of previous discussions.
Pl. Read my post again. I am not worried about when R1 will be released
I wanted to know the requirements , if it is laid out, for a R1 release or if some body will certify that this meets release requirements…..and who will certify this?
I’m not saying you, but this phenomenon has already happened for a long time
The requirements are here: Making sure you're not a bot!
Beta 6: Feb-March 2026 (proposed)
Ref: Haiku Activity & Contract Report, December 2025 | Haiku Project
Tickets (33 matches): Making sure you're not a bot!
Raspberry Pi and Chromium are ports. Tier 1 supported hardware is the real focus for device drivers and hardware platform support. Web browsers like IceWeasel work well enough. IP webcams (@3deyes) and 3D hardware acceleration (@X512 and others) are established working side projects using Haiku.
Release management (@waddlesplash and others) will crown the next victor…
Usually, a snapshot is announced (aka dinner bell announcement) for pre-testing the next OS release. You can boot and test the snapshot to foresee imminent issues before the official release.
You can do most of this boot-to-desktop and hardware device testing with the latest nightly release…
Thanks for this info
I am already using the nightlies…,.
That’s not quite true. No new features need to be added. We have already completed, not only the initial goal of replacing BeOS, but also the stretch goals from the R1 features poll. The remaining part is only fixing bugs.
The problem is, people enjoy working on new features more than fixing bugs. And these features can be very relevant to keeping Haiku a usable system in the modern age (such as having an up to date web browser, high resolution display support, more drivers, …).
The result is that R1 at this point is almost a side goal and not a high priority. Just enjoy the beta versions instead and stop worrying about version numbers. They cannot hurt you.
Maybe just renaming the stable to Haiku 2026 and subsequent releases this year 2026.1 etc, next year’s release 2027. No need for beta or R1. Everyone using it is in the know about the state of the release anyway, and it can be communicated on the site and news sites covering it.
What problem would it fix? Greek letters have no more meaning than year numbers. If “beta” is too emotionally loaded for some people we can switch to gamma, delta, … as well.
What is ist with people being so fuzzy about release names? Does that change anything for the better? I don’t get it.
I agree with Akafor. The whole business of alphas and betas is frankly not really relevant once you have a stable system, and we do. Let’s just forget R1 altogether. It’s not helpful.
Call the next release 2026.01 and go on from there. Aim to have a new release once a year, and more often if there is a major breakthrough.
It is not a matter of missing functionality like 3D acceleration, existing functionality should work properly first to be considered as ready for release.
I think the community would probably appreciate seeing a production release “R1” as a milestone release?
Then feel free to just do “year” or “year-month” releases after that, sure, whatever.
But seeing that first prod release is kind of a rush, and I think Haiku’s devs and longer-time users deserve that little hit of endorphins. 
I wouldn’t even mind having beta5 updated hrev with the latest “stable” fixes. 
If it’s not relevant to you, why do you want to change it? What problem does it solve?
Of course version numbers are not relevant. The OS will still be unstable and crashing at least once a week. The developers will continue to tell you “it’s not ready”. The roadmap will not really change.
So that’s focusing on the wrong part of the problem. The true question is: what should the developer do? Are you unsatisfied with the way things are headed currently, which is a lot of bugfixes, performance improvements, and the occasional new driver or major feature? Should we start work that has been put in the “R2” bucket and that will surely break existing apps more often? Should we redesign the whole user interface? With what goals?
Once you have done that, you can define the milestones to get there. And if you want to be fancy, you can name those milestones. But if your suggestion is just to rename the existing milestones, what’s the point?
We shall complete bug fixes and release R1 (before 2030 I guess). Cancelling R1.1 and R2 and turn to quarterly/yearly release is acceptable as long as R1 is finished.
I don’t care, but others do, and for the wrong reasons. Haiku is frequently criticised for still being in Beta after twenty years. It’s just a stick to beat Haiku with.
I have to concede I don’t use Haiku as a daily driver, but I am very surprised to hear that you are getting weekly crashes. Is this because you use nightlies?
And if you are not using nightlies, and not doing anything to encourage crashes, then I would agree that it is too early to suggest that Haiku is ready to be considered a viable alternative to Linux. It won’t be a viable alternative to Windows until Wine is working well.