FreeBSD Release Engineering: -CURRENT, -STABLE, and Shipping Releases

FreeBSD release names describe both a source branch and an operational promise. -CURRENT is active development, -STABLE is a maintained development line, and -RELEASE is a tested publication with a defined support window. They are not three quality settings selected from the same artifact. Code moves between branches under different review and freeze rules, while the Release Engineering and Security teams assume different responsibilities at different points in the cycle.

As of July 12, 2026, the Project’s live Release Engineering page identifies main as development for 16.0-CURRENT, stable/15 as development for 15-STABLE, and releng/15.1 as the frozen errata branch for the supported 15.1 release. FreeBSD 15.1-RELEASE was announced on June 16, 2026. Those facts will age; the branch model below is durable, but operators should always consult the current release and security pages before choosing an image or planning an upgrade.

`main` and `-CURRENT`: where integration happens first

The main branch of the src repository is the integration line for the base system: kernel, system libraries, commands, boot components, and supporting files. A checked-out and built main tree reports a version ending in -CURRENT. New interfaces and architectural changes normally land there first so developers and testers can expose interactions that one author’s machine cannot cover.

git clone -b main https://git.FreeBSD.org/src.git /usr/src
git -C /usr/src branch --show-current
git -C /usr/src log -1 --oneline

“CURRENT” means current development, not “latest recommended.” It may contain an incomplete transition, require coordinated world and kernel changes, or expose a regression between snapshots. The Project publishes development snapshots, but a snapshot is still a convenience build of a development branch, not a supported release. Running it responsibly requires reading the freebsd-current mailing list, keeping a recoverable boot environment or previous kernel, and being prepared to diagnose and report breakage.

The branch is valuable precisely because it receives wide testing before a change is considered for older lines. A useful bug report identifies the source revision, architecture, configuration, and reproduction steps; “16-CURRENT is broken” is not enough because two systems bearing that label may be many commits apart.

`stable/N` and `-STABLE`: conservative development, not a release

A major development line eventually becomes stable/N. Changes generally originate on main, receive testing, and are then merged to an applicable stable branch. FreeBSD calls this an MFC, historically “Merge From CURRENT.” The official release-engineering article documents a default minimum of three days before such a merge, with exceptions for cases such as critical fixes. Maintainers also judge whether the change is appropriate for the older line and whether its dependencies can be merged safely.

git clone -b stable/15 https://git.FreeBSD.org/src.git /usr/src
git -C /usr/src log --first-parent -5 --oneline

The word “STABLE” is easy to overread. It refers to a development branch whose compatibility and change policy is more conservative than main; it does not mean every commit has gone through a release cycle. The tip moves whenever approved changes land, so two 15-STABLE hosts can also run different revisions. Administrators tracking it compile and install source updates and own the testing needed for their local kernel options, third-party kernel modules, boot path, and applications.

Stable branches serve two roles. They provide a place to deliver suitable fixes before the next point release, and they are the source from which most point-release cycles begin. They are not patched copies of one numbered release. A later point release accumulates selected stable-branch work and then undergoes its own freezes and candidate testing.

From slush to BETA, RC, and RELEASE

Release Engineering publishes a schedule before cutting a release. A code slush asks developers to avoid disruptive changes and prepare pending work. A subsequent code freeze requires explicit Release Engineering approval for commits to the affected branch. Version metadata changes to PRERELEASE, then BETA builds are produced for broader testing.

During this stage, the goal is convergence. BETA reports reveal installer, upgrade, driver, package, and architecture problems under workloads that continuous integration cannot fully reproduce. Later Release Candidate builds carry an RC suffix and should contain only fixes justified for shipment. An RC is a release candidate, not an early supported release; production users should not silently turn a temporary RC installation into an unmanaged long-lived system.

For a point release, Release Engineering creates a dedicated releng/N.M branch. Access becomes progressively more restricted. The final -RELEASE artifacts—installation media, virtual-machine and cloud images, checksums, release notes, hardware notes, and errata—are built from the controlled release state. The announcement is the authoritative signal that the release is available, not the appearance of a file on a mirror during staging.

After release, the releng/N.M branch does not become general development. It receives approved security-advisory and errata changes. The Security Officer eventually owns approvals for that frozen branch. Meanwhile, stable/N continues moving toward later point releases and main continues toward a future major version.

What a machine’s version strings actually prove

Use both freebsd-version(1) and uname(1) when auditing a host:

freebsd-version -kru
uname -a

freebsd-version -kru reports the installed kernel, running kernel, and userland versions. They can differ after an update that installed a new kernel but has not yet rebooted, or midway through a multi-step major upgrade. A suffix such as 15.1-RELEASE-p2 identifies a patch level, but kernel and userland patch numbers do not always advance together: an advisory affecting only userland can leave the kernel version unchanged. That is why checking only uname -r can miss relevant state.

On a source-tracking system, also record the repository commit and any local modifications:

git -C /usr/src status --short
git -C /usr/src rev-parse HEAD

A custom kernel or locally patched tree can legitimately diverge from Project binaries, but it changes the update and incident-response procedure. Preserve the exact configuration and build provenance instead of assuming a familiar version label makes hosts identical.

Support belongs to releases, not vague major-version labels

The Security Information page lists supported releng branches and their estimated end-of-life dates. On July 12, 2026, it lists 15.1-RELEASE through March 31, 2027, 15.0-RELEASE through September 30, 2026, and the stable/15 series through December 31, 2029. Those dates may be extended, so automation should not bake this article’s snapshot into policy.

Production planning should track the specific release EOL, not only the major-series EOL. A major series may remain supported while an earlier point release no longer receives advisories. Subscribe to FreeBSD security announcements, review Security Advisories and Errata Notices, and schedule point upgrades before the installed branch expires.

For systems installed from supported binary distributions, the documented binary update path can apply security fixes and perform release upgrades. Source-built systems update from source instead. FreeBSD 15 also introduces packaged-base deployment choices, so operators should follow the procedure matching how that particular machine was installed rather than pasting an older freebsd-update recipe into every host.

Ports and packages follow a separate lifecycle

The src branch model governs the base system. The Ports Collection has its own main and quarterly branches, and package builders publish repositories derived from them. A supported base release does not imply that every third-party package is frozen for the same period or covered by the FreeBSD Security Officer. Package vulnerabilities are tracked through the VuXML database and surfaced by pkg audit.

Kernel modules from packages need special caution because they interface with the running kernel. A module built for an incompatible ABI or stale kernel can fail to load even when ordinary userland packages work. After kernel upgrades, verify the repository configuration and rebuild or reinstall locally built modules as the applicable documentation requires.

Release engineering is therefore a pipeline, not a marketing label:

main / 16-CURRENT
        | selected, tested merges
        v
stable/15 / 15-STABLE
        | slush, freeze, BETA, RC
        v
releng/15.1 / 15.1-RELEASE
        | security advisories and errata
        v
end of life

Most production systems should use a currently supported -RELEASE, keep its patch mechanism healthy, and rehearse upgrades. -STABLE fits teams that need post-release fixes and can build and test the base system. -CURRENT fits development and validation. Choosing intentionally—and recording exact revisions—is what turns FreeBSD’s branching discipline into operational predictability.

Related:

Sources: