FreeDOS Adopts Monthly Test Releases to Replace Release-Candidate Bottlenecks

FreeDOS began publishing automated monthly test releases in 2022, after FreeDOS 1.3. Distribution manager Jerome Shidel’s process regularly assembles current packages and installation media so changes can be tested together before the next stable version. The project names these builds Tyymm: T2603, for example, means the March 2026 test release.

The old process concentrated integration near a release

FreeDOS 1.4’s announcement explains that previous stable distributions required maintainers to gather packages into a release candidate and then repeat that process across several candidate iterations. Individual programs could be updated throughout the cycle, but system-level packaging and media issues became especially visible when a candidate was assembled.

That model creates a feedback delay. A new kernel, shell, installer, disk utility, localization package, or driver can pass its own tests and still fail when combined with another change. If the integrated image appears only near a stable release, maintainers must diagnose many accumulated differences at once.

Monthly builds reduce the size of that jump. They do not make every component correct; they make the current combination available often enough that a regression can be associated with a smaller interval and a concrete changes.log.

Tyymm identifies a month, not semantic stability

The naming convention encodes a two-digit year and month. It is deliberately different from stable release numbers such as 1.3 or 1.4. A higher T identifier means a later integrated snapshot, not necessarily a more stable one, and it does not promise compatibility equivalent to a final distribution.

FreeDOS’s March 2026 announcement calls the monthly image a “preview” or “test” release and says it contains the latest updates for combined testing. That label should survive when images are mirrored, attached to virtual-machine templates, or archived. Renaming a test ISO as “latest FreeDOS” strips away information a user needs for risk assessment.

Automation builds a complete distribution surface

The FreeDOS Release Build Environment does more than zip a package directory. Its builder project creates release and installation media. The rolling archive can publish LiveCD, LegacyCD, BonusCD, FullUSB, LiteUSB, and Floppy Edition artifacts, plus a generated report, error log, change log, README, and verification hashes.

This breadth is important because a change may work on the LiveCD and fail in the floppy installer, exceed one image’s capacity, conflict with a package category, or expose a boot difference between USB and older El Torito CD paths. Recurring builds exercise packaging assumptions that a single application maintainer may never encounter.

The builder itself is not an end-user package. Its official README describes a controlled build environment based on VirtualBox and openSUSE Leap and warns that other host arrangements are not officially supported. Users who only want to test FreeDOS should download generated media rather than running infrastructure installation scripts on a workstation.

Monthly tests did not abolish release candidates

The title’s “replace release-candidate bottlenecks” needs a precise boundary. FreeDOS still produced FreeDOS 1.4 release candidates; RC1 was announced on January 1, 2025. The monthly stream replaced the need to wait until candidate season for all integration, not the final candidate and stabilization gate itself.

The 1.4 announcement says an accumulated test release could become a release candidate when changes warranted a stable version. Candidates then provided a named freeze point for broader validation and release decisions. Continuous snapshots and candidates serve different purposes: one keeps integration feedback flowing, while the other narrows change before a final release.

FreeDOS 1.4 demonstrated the process

Monthly builds let users test FreeDOS 1.4’s package reorganization in public. The project removed confusing duplication between LiveCD and BonusCD, moved development-oriented tools to the bonus media, and reduced both image sizes. Repeated generation helped verify that packages still landed on the intended medium and installation profile.

The process also gives late upstream releases a predictable route. FreeDOS’s 1.4 announcement notes that Blocek 1.76 arrived too late for the final distribution and would enter an upcoming monthly test release instead. That is safer than silently replacing a package after final testing or delaying every other completed change until another multi-year stable release.

A test release requires disposable state

The correct testing target is a cloned virtual machine, a copy of a disk image, or hardware whose contents have been imaged and can be restored. A current snapshot may contain unfinished kernel, installer, partitioning, or memory-management changes. Installing it over the only copy of a working DOS environment defeats the purpose of risk-labeled media.

Useful test reports identify the exact Tyymm build, media type, package versions, CPU or emulator, memory configuration, storage layout, and steps needed to reproduce the result. The generated report.html and changes.log provide evidence about what the build contained. The hash list in verify.txt separates a corrupted download from a software regression.

Comparison matters more than “it works.” A tester can boot the prior stable release and the monthly build under the same configuration, then determine whether a failure is new. Capturing the last visible message, FDCONFIG.SYS, loaded drivers, and relevant logs gives maintainers something actionable.

Stable and test downloads must remain distinct

FreeDOS’s download page presents stable FreeDOS 1.4 separately from the monthly test release. Stable media represents a selected and finalized package set; test media prioritizes current integration and feedback. Neither label says that every old application or hardware combination is guaranteed, but they communicate different change risk.

The monthly system’s real achievement is shorter diagnostic distance. Package updates no longer need to wait years for an integrated audience, and stable release engineering no longer starts from a pile of components that have never shared generated media. By preserving names, logs, reports, and hashes, FreeDOS turns each month into an auditable test point while retaining release candidates as the final stabilization mechanism.

Related:

Sources: