Haiku R1/Beta 4 Closes Out 2022 with Broad Stability Work

Haiku R1/beta4 was released on December 23, 2022, roughly a year and a half after R1/beta3, which had shipped on July 26, 2021 following a timeline that was itself approved and later updated earlier that same year.

A release cadence that had, by now, settled into a recognizable rhythm

By this point, Haiku’s beta releases had established a clear pattern: roughly one to two years apart, each one accumulating a substantial number of bug fixes and incremental improvements across the system rather than centering on one dramatic new capability — the same pattern later continued with R1/beta5 in September 2024.

What continued to improve

Consistent with the project’s general trajectory since package management matured in the R1/beta1 era, beta4 continued the pattern of broad stability and compatibility improvements — hardware support, driver refinements, and bug fixes accumulated from real-world use of beta3 by the community feeding directly back into what shipped in beta4.

Why year-end releases aren’t unusual for a volunteer project

Shipping a release just before the end of the calendar year, as beta4 did on December 23, reflects the natural rhythm of a project without an externally-imposed release calendar — contributors converging on a release-ready state whenever the accumulated work actually reaches that point, rather than deliberately targeting a specific date for marketing or fiscal-year reasons the way a commercial software vendor’s release schedule often does.

Why tracking each individual beta’s specific date matters, even without a dramatic headline feature

For a project without a fixed release cadence, the actual gap between consecutive releases is itself meaningful information about project velocity and sustainability — comparing beta2 (2020) to beta3 (2021) to beta4 (2022) shows a project maintaining a roughly consistent, sustainable pace of major releases despite its volunteer-driven, contractor-supplemented resourcing, rather than either accelerating dramatically or stalling out entirely.

What stability work covered

The project’s announcement and notes describe hardware enablement, interface behavior, applications, POSIX compatibility, networking, and developer infrastructure. A December date does not prove rushed work; branch, test, and release processes determine quality. The useful comparison is documented Beta 3 behavior.

Beta remained an explicit warning

The R1 label describes compatibility goals, while Beta 4 communicates remaining risk. Users still needed backups and should not infer support from a chipset family alone. Hardware reports tied to PCI IDs, boot logs, architecture, and exact media were far more useful than general claims that Haiku did not work.

The release supplied a wider tested surface and fixed baseline for the next repair cycle—not a declaration that every driver or application was complete.

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

Do not compare beta quality by raw ticket totals alone. A release may close duplicates, documentation requests, regressions, and large features under the same counter. The release notes and linked issues provide scope; hardware test matrices and reproducible reports provide confidence. That evidence is more meaningful than calendar spacing between betas.

The release branch also separates stabilization from ongoing development. A fix merged to the main branch is not automatically proof that it shipped in Beta 4; verify the release note, tag, or branch history before assigning it to the image.

Preserve the image checksum and package list with test reports.

Related:

Sources: