Haiku R1/Beta1 Ships After Nearly Six Years of Work Since Alpha 4

On September 28, 2018, the Haiku project released R1/Beta1, its first beta-designated release — arriving nearly six years after Alpha 4, the last release in an alpha series that began with R1/Alpha 1 back in September 2009, and marking a significant milestone in the project’s long path toward a stable 1.0 release.

Why the gap between alpha and beta was so long

Haiku’s alpha releases were explicitly early, rough snapshots; the long stretch between Alpha 4 and Beta1 reflected the scale of engineering work required to bring the operating system’s package management system, driver support, and core application suite to a level the project considered genuinely beta-quality — including the package management system built on packagefs that fundamentally changed how software was installed and managed on Haiku.

What Beta1 actually delivered

The release included substantially improved hardware compatibility, a more complete WebPositive browser, and the maturing package management infrastructure that replaced Haiku’s earlier, more ad hoc software installation approach — collectively representing the difference between “an OS you experiment with in a VM” and “an OS approaching genuine daily-driver viability” for an increasing (if still small) group of users.

Why “beta” was a meaningful, deliberate label change

Moving from “alpha” to “beta” numbering wasn’t cosmetic — it signaled the Haiku project’s own assessment that the remaining work before a 1.0 release was refinement and stabilization of existing functionality, rather than building out fundamentally missing subsystems, a distinction that mattered for a all-volunteer open-source project managing expectations about its own maturity honestly.

The releases that followed

Subsequent beta releases — R1/Beta 2, Beta 3, R1/Beta 4, and R1/Beta 5 — continued this same steady, incremental refinement path, each shipping roughly one to two years apart as the project worked methodically toward an eventual stable 1.0.

Beta changed the reliability contract

Beta 1 did not claim complete hardware support. It established a stronger day-to-day baseline after the package-management transition, toolchain work, application updates, and broad stabilization. The official notes are authoritative because the release integrated hundreds of changes whose scope cannot be reduced to one feature.

A reproducible reference

Once Beta 1 existed, developers could compare failures with a fixed image rather than a moving nightly. Useful reports recorded architecture, package state, hardware IDs, and steps. Later fixes could be assessed as regressions or improvements against that baseline.

The six-year interval since Alpha 4 reflects integration and release readiness, not six years spent on one headline item. “Beta” communicates remaining risk while creating a version that ordinary users can test consistently.

Primary sources: official Beta 1 announcement, official release notes.

Release notes also define what not to claim. A feature present in a later nightly or beta cannot be assigned to Beta 1 without a matching note or source revision. When describing support, distinguish “driver exists,” “device initializes,” and “project declared supported”; those are different levels of evidence.

For preservation, keep both installation media and release notes with checksums. Repository contents can move, while a release image without its documented limitations invites inaccurate comparison. A virtual-machine appliance should record its emulated controller and firmware settings too.

Retain the original package state before testing updates, and record every repository change so a later result can be reproduced against the same Beta 1 environment.

Related:

Sources: