Ask HN: Why does FreeBSD do Releases the way the do?

> (a) there are 3 simultaneous production releases (13.0, 12.3, 12.2) - which seems confusing and lack of focus

Don't you mean 13.0, 12.2 and 11.4?

This is pretty common in other software too, isn't it? Ubuntu for example has 18.04 supported until 2023, 20.04 until 2025 and 22.04 (coming out soon) until 2027: https://ubuntu.com/about/release-cycle

Python has 4 supported versions: https://endoflife.date/python, and so does node: https://endoflife.date/nodejs.

> Don't you mean 13.0, 12.2 and 11.4?

Directly from freebsd.org front page, "Production: 13.0, 12.3, 12.2"

But to your point, it seems like FreeBSD could eliminate a branch since what equates to the "LTS" gets confusing due to the version methodology [0] in use.

Instead of the current flow of:

  CURRENT > STABLE > BETA* > RC* > RELEASE

Maybe a more approach version methodology would be:

  STABLE (stable major release) > CURRENT (testing minor release) > RELEASE (stable minor release)

                                   ^                                          | 
                                   |------------------------------------------

[0] https://www.freebsd.org/security/#sup

> Don't you mean 13.0, 12.2 and 11.4?

11.4 (and with it, the 11 major release) went out of support on September 30, 2021

12.2 will go out of support on March 31, 2022

Then it'll only be 13.0 and 12.2 supported; but 13.1 is expected to release in late April, and we'll have 13.1, 13.0, and 12.2.

First a general response:

There's a couple ways to run FreeBSD in production. Netflix does bleeding edge, and follows CURRENT, which is good for them because they do a lot of changes in the kernel, and want to upstream their changes, so staying up to date on CURRENT makes upstreaming easier which makes their life easier.

The other way is to use FreeBSD as a stable base, and only upgrade when you need it. In that way, you periodically validate new releases, and install new servers on your currently validated release, and leave existing servers with the release they were installed with, and sparingly update between releases when there's something important. Some choose to avoid .0 releases, and some choose to avoid X.Y where X % 2 == 1 (even numbered releases don't suck); although really it was only 5 that was worth skipping. Avoiding .0 releases may be obsolete as well, I seem to recall not having major issues with 13.0, 12.0, 11.0, and 10.0, but it's been a while. I wouldn't rush out to get a new major release, unless there was a very important feature/enhancement though.

Build your application software on a build machine that runs the oldest release that you run, be sure to install the compat_X packages so you can run older software on newer releases. If you run into bugs, expect to fix them yourself (that's what open source software is about, right?), and report them to upstream, and that they may be fixed in future releases. You'll need/want to develop a workflow where you fetch the upstream source for a release, apply your patches, and build world, release validation involves checking if your patches are still needed and updating them to still apply if needed. When releases are patched (ex 13.0-RELEASE-p7), it almost never breaks anything, so I would almost always build from the latest release patch when building a new server (there may be some exceptional versions), but I would read announcements to see if the change was relevant before updating servers. Minor versions are usually not a big deal either, but major versions often need patches updated and sometimes have major behavioral differences.

Now to your bullet points:

a) This shouldn't be confusing. Although maybe the presentation on the security page[1] is more (or less) clear. The 13.X series was released April 2021, and is expected to get security updates and critical patches until EoL, which is currently expected to be January 2026. The 12.X series was released December, 2018 and EoL is expected to be March 2022. This is a roughly 5 year commitment, rationale in the announcement [2]. Each minor release is supported through either 3 months beyond the next minor release of that major release or until the major release EoL, whichever comes first. FreeBSD plans to not have major releases more than once every two years, so there's at most three major releases supported at any given time.

b) It depends on the scope of the problem; bug fixes do get released onto branches, when it's justified. The expectation is that RELEASE branches are mature on release and won't change much. This isn't great if there's a bug that's important to you, but doesn't justify a fix in RELEASE for upstream.

c) This is at odds with your point in a. The FreeBSD team can only support so many releases, so they've said when a minor release is superseded, you get 3 months notice. Actually, if you follow along with upcoming release announcements, you get a bit more notice: 13.1 is currently in the release process, with a target date of April 26 (and the schedule was announced February 1); so we can anticipate 13.0 will end support near the end of July.

Also, it's important to note that the end of support doesn't mean your server turns into a pumpkin; just that you no longer have security advisories that specifically discuss your installed OS. If you keep abreast of security advisories in general, you can look into things that are reported on the software in base, and the currently supported releases and decide if it likely applies to the older versions and either backport fixes/workarounds or upgrade to a supported release.

If you consider your point in b, that you're not getting all that much support on the supported releases, losing support doesn't seem to be that big of a deal either. If you run into a bug, try it on one of your more updated servers (or update a server to try it on); if it's fixed, great, upgrade your impacted servers; if it's not fixed by upgrading then figure out how to fix it and if it's easier to fix in place or upgrade and fix at the same time.

e) This seems to be a rehash of a, but also c. If you want releases supported beyond the next release, they need to be listed. If you want to know what's happening with releases, the upcoming version should be listed. If you're having trouble picking which release to use, use the first one in the supported list, that's why it's there.

[1] https://www.freebsd.org/security/#sup

[2] https://lists.freebsd.org/pipermail/freebsd-announce/2015-Fe...

Can't say thank you enough for the massively informative and thorough response!

A few questions:

> You'll need/want to develop a workflow where you fetch the upstream source for a release, apply your patches, and build world, release validation involves checking if your patches are still needed and updating them to still apply if needed.

But doesn't that imply your having to fork FreeBSD just to use it. If so, doesn't that seem excessive for most organizations?

> The other way is to use FreeBSD as a stable base

You're not suggesting to use STABLE, correct. You'd still use RELEASE but rarely update it.

> Can't say thank you enough for the massively informative and thorough response!

No problem. Feel free to reach out via email (address on my profile), if you like. From many interactions in threads, it seems you've got an interest in FreeBSD and Erlang, which matches with my background. Always happy to answer your questions. :)

> But doesn't that imply your having to fork FreeBSD just to use it. If so, doesn't that seem excessive for most organizations?

Well, I wouldn't do it as a fork, because trying to manage it as a fork is exhausting (at least it was for me, when I took over after someone else had setup a fork, trying to move our patches from one releng branch to another was worse than with scripts, and just the pull and push for regular updates was tedious; it probably gets better with practice). At WhatsApp, we had a script that had the release (ex 12.1) at the top, and it would pull the latest from that release branch, apply the handful of patches (/usr/bin/patch < foo.patch || exit), and then run make world/makekernel and then implore the operator to run make install. It wasn't a big script, and we didn't have many patches. You need/want some sort of setup script anyway, so it may as well pull in a couple patches, and make world is a reasonable burn-in test for new servers. You could probably centralize and build binary updates for your fleet too, but we never did. If your organization ends up with zero patches, then it's even easier. I don't think it's unreasonable to expect an organization to do some effort to mange the OS they run on, but honestly, I don't know what the alternative is.

The more important to the business a piece of software, the more likely it is to need a couple patches here and there; for us, all of our servers ran it, so it was kind of important (although, we did end up switching to Linux to harmonize with FB's systems, and that seems to have worked out well enough[1], but then FB had a team to manage the Linux OS install as well). We also had patches for Erlang, and a couple lighttpd patches (nothing exciting), and maybe some for yaws (an Erlang webserver). As a rule, software is broken, but open source lets you fix it :D

> You're not suggesting to use STABLE, correct. You'd still use RELEASE but rarely update it.

Yes, exactly. I don't think I've ever really used STABLE; either CURRENT for bleeding edge testing/development (when needed) or RELEASE for regular production.

[1] there are things that broke, but were fixed (or worked around) easily, and things I liked better on FreeBSD, but mostly I avoided the Linux systems until we ran out of FreeBSD systems, then I quit. :) A lot of the things I disliked were related to how Facebook runs their systems, and I doubt that running on FreeBSD instead would have changed those things; it just would have meant that we would have to port things to FreeBSD that we (or at least I) didn't like anyway. :)

Why are you asking here instead of on the FreeBSD mailing list or forum?

You don't get clicks on the FreeBSD mailing list.