FreeBSD’s Release Cycle: What It Means for Your Upgrade Schedule

If you come from the Linux world, FreeBSD's release model takes a moment to click. There is no separation between “the kernel” and “the distribution” — the FreeBSD Project develops the kernel, the userland, and the build system in a single source tree and ships them together as one operating system. That single tree is cut into branches, and understanding those branches is understanding the release cycle. Once you see how code flows from development to a supported release, the version numbers, the EoL dates, and the upgrade expectations all fall into place. 

Three Kinds of Branches

Everything starts in one Git repository with three kinds of branches. 

main (FreeBSD-CURRENT)

main, also called FreeBSD-CURRENT, is the development head. Today it identifies itself as 16.0-CURRENT. All new work lands here first: new drivers, new subsystems, and ABI-breaking changes. The FreeBSD Handbook is blunt about who should run it — developers, testers, and people who accept breakage. It is the rough equivalent of tracking the mainline Linux kernel plus a rolling userland at the same time. Production systems have no business here. 

For those organizations that build atop FreeBSD, there is a significant advantage to building and testing the latest features and fixes. In the FreeBSD development cycle, there is the “stabweek”, the last week of each month which is dedicated to stabilizing the main branch. Risky changes are discouraged, and the focus is on bug fixes, giving everyone who tracks CURRENT a common point to update to and test together. Each stabweek starts with an automated email to freebsd-current@ naming a tagged revision (e.g., main-stabweek-2026-Jul) for participants to test and runs until Friday 18:00 UTC. This coordinated testing ensures any issues in the main branch are found and fixed quickly, and that those shipping bleeding-edge features can safely move from stabweek tag to stabweek tag.

stable/N Branches

stable/15, stable/14 and so on are the stable branches. When a major version is ready, a stable/N branch is forked from main, and changes that have proven themselves in CURRENT are merged back into it; a process FreeBSD calls MFC, “merge from current.” The word “stable” here describes the ABI, not the maturity of every commit. Within a stable branch, kernel interfaces and the userland ABI stay compatible, so that a binary built for 15.0 keeps running on 15.1 and 15.2. The Handbook still calls it a development branch, though. If you don’t have the resources to continuously validate a rolling release, you should run releases, not stable. 

releng/N.M Branches

releng/15.1, releng/14.4 and so on are release branches. Shortly before each release, a releng/N.M branch is cut from stable/N. From that point it is frozen: every commit needs explicit approval from the release engineering team, and after the release ships, the branch receives only security fixes and critical errata. This is what your production machines actually run. 

So the flow is: main → MFC → stable/N → BRANCH → releng/N.M → RELEASE. In Linux terms, a stable branch behaves a bit like a distribution’s development series with a strict ABI promise, and a releng branch is the point release you deploy. 

From Branch to RELEASE: How 15.1 Shipped

The process is visible in public schedules, so let’s use the most recent release, FreeBSD 15.1, as an example. 

On April 17, 2026 the stable/15 branch entered “code slush”; a cool-down period where disruptive changes are discouraged ahead of branching. On May 1, the releng/15.1 branch was created, and from then on every commit to it required release-engineering approval. The same day, BETA1 was built. Additional beta builds followed weekly (BETA2 on May 8, BETA3 on May 15), then the release candidates: RC1 on May 22, RC2 on May 30, RC3 on June 5. Final builds started June 12, and 15.1-RELEASE was announced on June 16, 2026. 

That is the template for every release: slush, branch, a few weekly BETAs, a few RCs, ship. Roughly two months from branch to announcement, all of it is published in advance on the release engineering page. If you want to test a release against your workload before it ships, the BETA and RC images exist exactly for that purpose. 

The Cadence 

FreeBSD aims for a new major version roughly every two years, with minor releases from the active stable branches in between. The project publishes the target schedule years ahead. As of today, it looks like this: 14.5 in September 2026, 15.2 in December 2026, 14.6 in March 2027, 15.3 in June 2027, and 16.0 in December 2027. 

The version string tells you where a system sits in this model. In 15.1-RELEASE-p2, the 15 is the stable branch it came from, .1 is the second release off that branch (counting from .0), and -p2 means two batches of post-release security patches have been applied to the releng branch. A machine reporting -STABLE or -CURRENT instead of -RELEASE is tracking a development branch rather than a point release. 

Two stable branches are typically alive at once. The newest one produces “production releases” — currently 15.1 — while the previous branch keeps producing “legacy releases” (14.4, soon 14.5) for users on a conservative upgrade path. In practice, each branch puts out a minor release about every six months until the end of the branch after 4 years. 

What "Supported" Means, and for How Long

Support in FreeBSD terms means security advisories and errata notices from the FreeBSD Security Team, plus binary patches you can pull with freebsd-update or the new pkgbase tools. The lifetime rules are simple but stricter than many people expect: 

1. A stable branch is supported for four years from its .0 release (this policy starts with FreeBSD 15; stable/15 is supported until December 31, 2029, and stable/14 until November 30, 2028). 
2. An individual minor release is supported only until three months after the next minor release on the same branch. 

Rule 2 is the one that catches teams off guard. 14.3-RELEASE came out in June 2025; when 14.4 shipped on March 10, 2026, it started the clock on 14.3, which reached end-of-life on June 30, 2026. Right now, the supported picture looks like this: 

After an EOL date, there are no more advisories and no more patches for that release — even if a vulnerability is found the next day. 

The upgrade mechanism itself is not the hard part. Minor and major upgrades are handled by the same tool, with binary updates and no recompiling: 

# What am I running, and is it patched? 

$ freebsd-version -kr 

15.0-RELEASE-p2 

15.0-RELEASE-p2 


# Move to the next minor release on the same branch 

$ freebsd-update -r 15.1-RELEASE upgrade 

$ freebsd-update install 

# reboot, then run `freebsd-update install` again to finish userland 

Because the ABI holds within a major version, a minor upgrade like 15.0 → 15.1 is normally uneventful. Major upgrades (14.4 → 15.1) are also supported by freebsd-update, but you should expect to reinstall all third-party packages to versions built against the new ABI and carefully read the release notes. 

Planning Around the Cycle

Put the rules together, and the operational rhythm becomes clear. Staying on supported FreeBSD means taking a minor upgrade roughly every six months, with a three-month grace window once the next minor appears, and a major upgrade every couple of years before your stable branch hits its four-year limit. For a handful of well-automated servers, that cadence is entirely reasonable; arguably healthier than the “install and forget for a decade” habit some Linux LTS distributions encourage. 

Not every environment can move that fast, though. Appliances shipped to customer sites, storage clusters that only get maintenance windows twice a year, or stacks frozen by certification requirements can easily find themselves still running a release the day its advisories stop. The project’s dates don’t bend for anyone’s change-control calendar. If your reality looks like that, it’s worth knowing that longer support horizons for FreeBSD than the project itself provides are becoming a realistic option, a topic we’ll return to. 

For everyone else: check freebsd-version, note your EoL date, and put the next minor release in your calendar. The schedule is public; the cycle rewards the teams that read it.