potential FreeBSD convert / FreeBSD release cadence

[FBachofner]

Hello All!

After 1.5 decades business (longer for personal use) experience with various Linux distributions (generally Fedora as of 4 or 5 years ago), I am seriously contemplating moving various of my servers to FreeBSD.

I expect I will have a number of "newbie" questions here over the next days, but perhaps my most important relates to the FreeBSD release cadence, which is quite critical to me from a planning standpoint as I would also be installing FreeBSD on servers of many/most of my business' clients.

Looking diligently at various docs and the schedule published on FreeBSD Release Engineering Information it seems as if FreeBSD is now holding fairly closely to a cadence of 2x "minor" releases per year per "major" version ... with major version upgrades at ~24 months. This corresponds somewhat to the article I found @ TheTechAdvocate, although they seem to suggest major releases will be annual.

Is there any reason to believe / "fear" that this fairly new cadence might change suddenly or that significant milestone slippage will throw off the planned cadence at any "near" point.

Thank you in advance for your insights! I really hope this new apparent release cadence is reliable or I will only be able to "play" with BSD as opposed to migrate in earnest.

 

[FBachofner]

Small addendum:

In reading the anticipated release schedule for the upcoming 14.3, I see that support EOL for 14.2 is only 3 months after the planned release of 14.3. [ This seems very short, but OK, perhaps FreeBSD wants any semblance for "long term" support only on the major versions?]

This is NOT similarly indicated for 14.2 and 14.1 which don't show a planned EOL, so I am confused. [BTW, it's fantastic that the URLs to the documents are named so consistently and logically !! ]

 

[FBachofner]

"Final" addendum:

I just read to the very bottom of the 14.0 release announcement which states "This point release, FreeBSD 14.0-RELEASE, will be supported until at least three months after FreeBSD 14.1-RELEASE."

So . . . does the entire community generally update every system every 6 months or do many run "unsupported?"

I have been reading that FreeBSD updates are fairly trivial (and my very positive 2-year experience with OPNSsense certainly suggests that), but I am still intrigued at what almost seems like a "forced" upgrade cadence.

 

[eseipi]

Hi FBachofner,

So . . . does the entire community generally update every system every 6 months or do many run "unsupported?"

There is a big difference between major and minor releases of FreeBSD. Please check Thread 79890, I believe you may find some useful information there. In short: yes, it's expected that the base system remains updated, but the ABI is kept stable between minor releases.

This is NOT similarly indicated for 14.2 and 14.1 which don't show a planned EOL, so I am confused.

Yep, older schedule tables don't seem to contain expected EOL dates, only newer ones do, which may be slightly more convenient. In general, just like you said, each minor release is EOL'ed in about 3 months after its successor from the same stable branch is available.

Is there any reason to believe / "fear" that this fairly new cadence might change suddenly or that significant milestone slippage will throw off the planned cadence at any "near" point.

I don't think anybody knows for sure. The current 5-year lifetime guarantee was officially announced in 2015, but unofficially it was present since FreeBSD 5.x (see https://lists.freebsd.org/pipermail/freebsd-announce/2015-February/001624.html for details), which is from 2003. Starting with 15.x, support duration will be reduced to 4 years indeed (https://lists.freebsd.org/archives/freebsd-announce/2024-July/000143.html), but it would be fair to notice that this whole policy is lasting quite a while, and still hasn't changed much.

 

[cracauer@]

There is little reason to fear point releases, unless you run kernel modules out of packages, which you probably won't on servers.

Keep in mind that ports and packages are a rolling thing, or quarterly. There can be a lot more work in there than for the base system upgrades. It is not like Debian where suddenly everything changes all at once with major releases. In FreeBSD, for ports/packages, you have your breakages sprinkled over time.

 

[Erichans]

I don't think anybody knows for sure. The current 5-year lifetime guarantee was officially announced in 2015, but unofficially was present since FreeBSD 5.x (see https://lists.freebsd.org/pipermail/freebsd-announce/2015-February/001624.html for details), which is from 2003

IIRC, in past (long before 2015) there was at some time a difference between odd and even minor versions in terms of LTS.

This corresponds somewhat to the article I found @ TheTechAdvocate, although they seem to suggest major releases will be annual.

That is likely what this article in your link is referring to.

Leaving history behind, the February 2015 mailing list announcement is what at the moment 'governs' present day FreeBSD, apart from the recent announcement by Colin Percival (LTS as known and with its specific meaning on various Linux distributions does not exist for FreeBSD). This detailed announcement is (as far as I can tell) only mentioned at FreeBSD Security Information at the very bottom at The FreeBSD support model (the overview of currently supported FreeeBSD versions, you'll find at Supported FreeBSD releases just above it). In my view this is much too terse and may easily give the wrong impression (like: "I choose 14-STABLE because that has the longest suport"). I tried to word it better here.

Is there any reason to believe / "fear" that this fairly new cadence might change suddenly or that significant milestone slippage will throw off the planned cadence at any "near" point.

In general FreeBSD has, in my view, a history of gradual change and not changing things overnight according to what seems fashionable. How this 'fairly new cadence' will affect the (supported) FreeBSD landscape is still unknown, as it is mostly only starting at FreeBSD 15.x; at the moment that's is -CURRENT. See also here for some context in the form of video presentation about the change in FreeBSD's Support Model initiated by Colin Percival as the lead of the Release Engineering Team. Clear is that the cadence will be upped by the transition from five to a four-year support period for each major branch (aka major FreeBSD version, as 13.x and 14.y); however, I'm strengthened by the projected changes and their implementation, as can be viewed in the release engineering session, led by Colin Percival and Gordon Tetlow in the above mentioned video presentation.

If you are contemplating for a FreeBSD change for a sizable number of servers/workstations then, I suggest you consider two further aspects: package building from source as part of your local package building and package maintenance; and ZFS.

Perhaps you've already experienced ZFS on Linux, but I'd like to focus on a particular aspect of ZFS that can be an enormous help/advantage in upgrade management and as a fallback option: Boot Environments*; my earlier written overview here with related links may be helpful in that aspect. This relates to both upgrades of the base system as to package upgrades.

As hinted by cracauer@ package management is rather different from that in most Linux distributions. The general recommendation is to use packages instead of ports (and building packages from ports' sources yourself) but, you may find that only package use will not be sufficient. For example you need specific port options that are not enabled by the default port settings which are used by the FreeBSD package builders, or there isn't a specific flavor (package) of a specific port that you need. In those cases you should consider building and maintaining your own packages within your local server network. This is probably even more relevant if you choose to use packages/port based on 'latest' (as opposed to 'quarterly'; the default for 14.x-RELEASE on amd64 architecture). poudriere(8), the Handbook and Poudriere: Getting Started - Tutorial may guide you further.

___
* Only recently a Linux variant as been made available: ZBM 101: Introduction to ZFSBootMenu

 

[FBachofner]

Hello eseipi cracauer@ and Erichans

WOW! what a fantastic "introduction" to the FreeBSD community. I will take a detailed look at your links over the next few days.

 

[FBachofner]

Hi Erichans

I suggest you consider two further aspects: <snip> and ZFS.

The incredible "reliance" of FreeBSD on ZFS is actually one of my concerns. I was actually going to start another thread entirely, but ...

For smallish, noncritical datasets (which are nevertheless backed up) I'm not a fan of pools using multiple software-raided disks. Such an approach adds significantly to my cognitive load with regard to the system hardware (i.e. disks).

I have been doing things like dedicating a single disk to each of various data "types" such as database(es), video, photos. This makes it stupid simple to backup [i.e. just take the same size disk and (oversimplifying) make a copy] and it is fairly trivial to add capacity (which seems to be ZFS' Achilles heel. In most of our scenarios, as video storage demand grows, that disk gets replaced with something much larger and the inadequate gets "handed down" to the nextmost capacious in demand and so on.

I am of course willing to entertain a lesson on how I am being stupid (inefficient, whatever), but at the moment I anticipate using UFS if coming over to FreeBSD. That may be silly, however. Perhaps UFS is not as "good" as ext4?

Also, something I don't know much about: what about single-disk ZFS pools? This probably has various benefits over UFS-formatted disks (while certainly "loosing" others benefits in relation to multi-disk ZFS).

However, a JBOD disk arrangement would certainly ease my cognitive load.

Your thoughts would be welcome here if the moderators don't want me to move this question to another thread.

 

[cy@]

"Final" addendum:

I just read to the very bottom of the 14.0 release announcement which states "This point release, FreeBSD 14.0-RELEASE, will be supported until at least three months after FreeBSD 14.1-RELEASE."

So . . . does the entire community generally update every system every 6 months or do many run "unsupported?"

I have been reading that FreeBSD updates are fairly trivial (and my very positive 2-year experience with OPNSsense certainly suggests that), but I am still intrigued at what almost seems like a "forced" upgrade cadence.

This isn't different from Red Hat (which I maintain 1400 RHEL servers at $JOB). Let's take RHEL 9 as an example. The RHEL 9 channel is a stream of RPMs. Call it a rolling release if you may, though it is not. RHEL 9.2 is a point release Red Hat will release patches (RPMs) for this subchannel.

Consider FreeBSD 14-STABLE a channel. Unlike RHEL binary users (freebsd-update or pkg) cannot track 14-STABLE. Those who buildworld/installworld from source can. And it changes moment to moment (after some testing in FreeBSD 15-CURRENT). Security and errata patches for FreeBSD point releases, i.e. 14.2, are released through freebsd-update or pkg. Src users can also track this if they wish.

Consider FreeBSD 15-CURRENT like Fedora. Fedora is at version 41. It's a rolling update. Similarly FreeBSD 15-CURRENT is a rolling update. Fedora updates are binary patches. FreeBSD 15-CURRENT is commits to our git repo. One can build (buildworld) and install (installworld). As a developer I regularly build and install FreeBSD on a set a test platforms -- not because I'm a glutton for punishment but I want to keep on top of any changes to FreeBSD that might affect parts of FreeBSD I maintain. But, some non-developer users also use 15-CURRENT. -CURRENT gets support for new devices and new features sooner than the -STABLE and -RELEASE branches do. New features and devices are typically not merged (backported) to -STABLE or -RELEASE for fear of horribly breaking something. -CURRENT, like Fedora , does sometimes break (like Fedora 41 broke X last month).

FreeBSD is kind-of like Gentoo. Or should I say, Gentoo Linux is kind-of like FreeBSD, in the sense they copied the FreeBSD approach of the user can build everything from us. FreeBSD is closer to UNIX of old when source reigned supreme, but with a twist. You can install and maintain your FreeBSD install with binary only updates. IMO it's a good compromise.

 

[tingo]

One more point to note (if you haven't already): whenever an FreeBSD OS (=operating system) version goes to "unsupported", the package updates also goes "unsupported". In practical terms, that means you can not install any more packages via pkg(8), as the tool will tell you that that the package database (for your version of the OS) no longer exists.
(if you have a local *.pkg file and the dependencies match you can install that. YMMV)