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 cannot imagine any reason why somebody would want to use RELEASE for production.
I used FreeBSD at Yahoo and WhatsApp, using RELEASE at both. I'm sure there were some times where some groups were running other than RELEASE (and they were running Yahoo builds anyway), but at both places when I was there, we didn't have habit of upgrading the OS. To my knowledge, none of the servers I ran at Yahoo had an OS update installed, I'm not sure there was a procedure; we would get a server it would have the then latest Y! FreeBSD build, we would install our stuff and go for 3-5 years until the server was sent to recycling. Most of our servers never rebooted.
That pattern doesn't really fly today, lots of kernel security fixes and what nots, so you've got to do updates and reboots. At the time, running a miminal kernel and minimal services meant most security updates were for things not on our machines or could be updated without rebooting or doing a full upgrade cycle.
Using RELEASE makes it easy to understand what host has what, rather than -STABLE from whatever day it was installed. This is pretty handy when you've got a mixed fleet of whatever was current when they were installed.
Towards the end of my time at WhatsApp, I did work on keeping our fleet more current, mostly because we had more servers where they didn't need hardware upgrades for a long time, so they didn't get OS refeshes. Running 4 different major versions is irritating in ways that are most easily addressed by doing the upgrade work.
The only time we ran outside of -RELEASE at WhatsApp was very ocassionally to confirm kernel patches we wanted to upstream, but we didn't have a lot of patches, not all of them were important to upstream, and many of them didn't need a report from CURRENT.
Some releases would have important upgrades that really helped some workloads so we'd push those, but at least I would find those out from reading release notes, not following development closely. Or sometimes we'd find out by accident... if a server lost its disk and we set up the replacement with a newer release and perf was significantly different, we'd try to figure out what changed and if perf was better, we might upgrade the other servers for that workload.
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.
* https://www.freebsd.org/security/#sup
(Yes. I know.)
Linux distros only recently started doing this with the rise of flatpaks on top of immutable distros (or Debian stable).
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).
“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?)
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.
> $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.
I used FreeBSD at Yahoo and WhatsApp, using RELEASE at both. I'm sure there were some times where some groups were running other than RELEASE (and they were running Yahoo builds anyway), but at both places when I was there, we didn't have habit of upgrading the OS. To my knowledge, none of the servers I ran at Yahoo had an OS update installed, I'm not sure there was a procedure; we would get a server it would have the then latest Y! FreeBSD build, we would install our stuff and go for 3-5 years until the server was sent to recycling. Most of our servers never rebooted.
That pattern doesn't really fly today, lots of kernel security fixes and what nots, so you've got to do updates and reboots. At the time, running a miminal kernel and minimal services meant most security updates were for things not on our machines or could be updated without rebooting or doing a full upgrade cycle.
Using RELEASE makes it easy to understand what host has what, rather than -STABLE from whatever day it was installed. This is pretty handy when you've got a mixed fleet of whatever was current when they were installed.
Towards the end of my time at WhatsApp, I did work on keeping our fleet more current, mostly because we had more servers where they didn't need hardware upgrades for a long time, so they didn't get OS refeshes. Running 4 different major versions is irritating in ways that are most easily addressed by doing the upgrade work.
The only time we ran outside of -RELEASE at WhatsApp was very ocassionally to confirm kernel patches we wanted to upstream, but we didn't have a lot of patches, not all of them were important to upstream, and many of them didn't need a report from CURRENT.
Some releases would have important upgrades that really helped some workloads so we'd push those, but at least I would find those out from reading release notes, not following development closely. Or sometimes we'd find out by accident... if a server lost its disk and we set up the replacement with a newer release and perf was significantly different, we'd try to figure out what changed and if perf was better, we might upgrade the other servers for that workload.
These days, I always use RELEASE and apply patches with freebsd-update.
Also, real businesses use -CURRENT, everybody knows that.
No, not really.
https://people.freebsd.org/~gallatin/talks/OpenFest2023.pdf
https://arstechnica.com/gadgets/2021/03/buffer-overruns-lice...
Most users will neither be willing nor able to accept the trade-offs that Netflix chose.
Edit: I love HN. I'm obviously joking, but instant 4 downvotes
We're allowed to have fun, guys.