Having multiple maintained versions isn't a mystery. (Although figuring out which one you want might be; I'm.... 80%... sure you want the highest numbered "RELEASE", not "STABLE", but not 100%).
Nobody asked, but a quarter century ago we used FreeBSD stable with current ports in a small business setting. A mostly unchanging base system but always the most recent user facing software (KDE iirc).
Linux distros only recently started doing this with the rise of flatpaks on top of immutable distros (or Debian stable).
I cannot imagine any reason why somebody would want to use RELEASE for production.
A RELEASE is good for installing FreeBSD on a new computer, or for upgrading from a previous major version of FreeBSD, e.g. from 13 to 14 or from 14 to 15.
After installing a RELEASE, you normally update it to STABLE, before starting to use the computer.
STABLE versions correspond to the long-term-support versions of Linux, i.e. they include only essential back-ported patches, like security patches or bug fixes.
RELEASE are the initial versions, like a Linux x.x.0 version, which may have various problems that are discovered later and corrected in the STABLE versions.
I have been running FreeBSD continuously 24/7 on many servers for more than a quarter of century, and I have always used STABLE on them (after installing RELEASE first, especially when upgrading from an older major version, to minimize the risks of incompatibilities).
Yes, looking at the current handbook, today you are right and my posting was wrong.
However, this is because the policy of FreeBSD has changed. Decades ago, when I started using FreeBSD, STABLE was like I said, the recommended branch for production and frequently it was strictly necessary to update to STABLE because it had important patches missing in RELEASE.
It appears that they have changed this some years ago.
However, I was oblivious to this, because it did not affect me as I do not track automatically their STABLE versions, but I do only some audited updates.
The description of STABLE as a development branch to be followed with caveats, and that using it is an active process with risks you need to mitigate has been in the handbook since at least 1996 (https://freshbsd.org/freebsd/doc/commit/827b1b2b292dd02f9bc9...):
> FreeBSD-stable is our development branch for a more low-key and conservative set of changes intended for our next mainstream release.
..
> If you're a commercial user or someone who puts maximum stability of their FreeBSD system before all other concerns, you should consider tracking <em>stable</em>
..
> Please note that the <em>stable</em> tree endevors, above all, to be fully compilable and stable at all times, but we do occasionally make mistakes (these are still active sources with quickly-transmitted updates, after all)
Indeed, the first step to tracking stable is to join the mailing list:
> <heading>Using FreeBSD-stable</heading>
> <p><enum><item> Join the freebsd-stable mailing list.
So the nature of the branch hasn't really changed, it's more that there's now much less reason to track it - we have regular patch releases, and the ports system no longer only supports CURRENT and STABLE.
I've been using FreeBSD since 1996, both commercially and as a hobbyist.
Early on, back in the CVS days, I would do a you describe, building STABLE out of /usr/src.
These days, I always use RELEASE and apply patches with freebsd-update.
You're just wrong. FreeBSD stable branches are the development branches from which new minor releases (with a stable ABI) are forked. If you want to be pedantic you want to follow the releng branches for most production deployments (release + security and non-security errata patches). Unless you build from source yourself you the tools (pkgbase, freebsd-update) don't make that distinction visible to the user.
A CDN *cache* server is a special case. Netflix cache appliances can accept the risk of running FreeBSD -CURRENT and upgrading half their fleet to the latest snapshot every ~2 weeks and we thank them for battle testing FreeBSD's active development branch in production. It really helps to reveal regressions (both correctness and performance) early in the subsystems and drivers that matter to their usecase.
Most users will neither be willing nor able to accept the trade-offs that Netflix chose.
The latest release of FreeBSD with i386 images. The 14.x branch is the last to support the platform.
The 14.x branch has an expected end of life (EOL) of November 2028:
* https://www.freebsd.org/security/#sup
Oh, sweet mystery of FreeBSD versioning. 15.1-Release already came out.
(Yes. I know.)
Having multiple maintained versions isn't a mystery. (Although figuring out which one you want might be; I'm.... 80%... sure you want the highest numbered "RELEASE", not "STABLE", but not 100%).
Nobody asked, but a quarter century ago we used FreeBSD stable with current ports in a small business setting. A mostly unchanging base system but always the most recent user facing software (KDE iirc).
Linux distros only recently started doing this with the rise of flatpaks on top of immutable distros (or Debian stable).
username checks out
pfSense is -CURRENT, Netflix OCA is -CURRENT, etc. It's not too hard.
https://forums.freebsd.org/threads/pfsense-software-embraces... :)
That seems to be an "April Folks Joke"
For production, yes, use RELEASE.
I cannot imagine any reason why somebody would want to use RELEASE for production.
A RELEASE is good for installing FreeBSD on a new computer, or for upgrading from a previous major version of FreeBSD, e.g. from 13 to 14 or from 14 to 15.
After installing a RELEASE, you normally update it to STABLE, before starting to use the computer.
STABLE versions correspond to the long-term-support versions of Linux, i.e. they include only essential back-ported patches, like security patches or bug fixes.
RELEASE are the initial versions, like a Linux x.x.0 version, which may have various problems that are discovered later and corrected in the STABLE versions.
I have been running FreeBSD continuously 24/7 on many servers for more than a quarter of century, and I have always used STABLE on them (after installing RELEASE first, especially when upgrading from an older major version, to minimize the risks of incompatibilities).
This is not correct, stable is a dev branch, so you’ve been running your 24/7 machines off of unreleased code:
“FreeBSD-STABLE is the development branch from which major releases are made.”
(https://docs.freebsd.org/en/books/handbook/cutting-edge)
probably works, but i’m not doing that on my prod thanks. (perhaps you’re thinking of the releng/foo branches instead?)
Yes, looking at the current handbook, today you are right and my posting was wrong.
However, this is because the policy of FreeBSD has changed. Decades ago, when I started using FreeBSD, STABLE was like I said, the recommended branch for production and frequently it was strictly necessary to update to STABLE because it had important patches missing in RELEASE.
It appears that they have changed this some years ago.
However, I was oblivious to this, because it did not affect me as I do not track automatically their STABLE versions, but I do only some audited updates.
The description of STABLE as a development branch to be followed with caveats, and that using it is an active process with risks you need to mitigate has been in the handbook since at least 1996 (https://freshbsd.org/freebsd/doc/commit/827b1b2b292dd02f9bc9...):
> $Id: stable.sgml,v 1.1 1996-02-11 00:16:17 jkh Exp $
> FreeBSD-stable is our development branch for a more low-key and conservative set of changes intended for our next mainstream release.
..
> If you're a commercial user or someone who puts maximum stability of their FreeBSD system before all other concerns, you should consider tracking <em>stable</em>
..
> Please note that the <em>stable</em> tree endevors, above all, to be fully compilable and stable at all times, but we do occasionally make mistakes (these are still active sources with quickly-transmitted updates, after all)
Indeed, the first step to tracking stable is to join the mailing list:
> <heading>Using FreeBSD-stable</heading>
> <p><enum><item> Join the freebsd-stable mailing list.
So the nature of the branch hasn't really changed, it's more that there's now much less reason to track it - we have regular patch releases, and the ports system no longer only supports CURRENT and STABLE.
If you run the latest (laptop) hardware you may still have to track stable or backport some patches from -CURRENT.
I've been using FreeBSD since 1996, both commercially and as a hobbyist. Early on, back in the CVS days, I would do a you describe, building STABLE out of /usr/src.
These days, I always use RELEASE and apply patches with freebsd-update.
You're just wrong. FreeBSD stable branches are the development branches from which new minor releases (with a stable ABI) are forked. If you want to be pedantic you want to follow the releng branches for most production deployments (release + security and non-security errata patches). Unless you build from source yourself you the tools (pkgbase, freebsd-update) don't make that distinction visible to the user.
Yeah, but which one?
Also, real businesses use -CURRENT, everybody knows that.
14.x-RELEASE if you still need i386 support, 15.x-RELEASE if you are installing new and want the longest longevity.
Nobody is running i386 in production, I would think. It’s fun to imagine someone actually might be…
> Also, real businesses use -CURRENT, everybody knows that.
No, not really.
I have thousands of CDN servers that would disagree with you.
https://people.freebsd.org/~gallatin/talks/OpenFest2023.pdf
A CDN *cache* server is a special case. Netflix cache appliances can accept the risk of running FreeBSD -CURRENT and upgrading half their fleet to the latest snapshot every ~2 weeks and we thank them for battle testing FreeBSD's active development branch in production. It really helps to reveal regressions (both correctness and performance) early in the subsystems and drivers that matter to their usecase.
Most users will neither be willing nor able to accept the trade-offs that Netflix chose.
Netflix is just a single point. I'd never run current in production.
It may be more common than you think. The latest version of pfSense CE is on 16.0-CURRENT.
PFsense gleefully ships vulnerable code to their own customers. They are an even worse data point
https://arstechnica.com/gadgets/2021/03/buffer-overruns-lice...
-CURRENT is great for cattle. For pets, I recommend -RELEASE.
Akshually-
Edit: I love HN. I'm obviously joking, but instant 4 downvotes
We're allowed to have fun, guys.
Present and accounted for ^^
supported platforms: https://www.freebsd.org/releases/14.5R/hardware/#proc