alt Hacker NewsI 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).
Replies
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?)
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.
> 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.