15.0 release only until September 2026?

RELEASE announcement
2 December 2025

-

15.0-RELEASE press release.

15.0 EoL

30 September 2026

-

15.0-RELEASE no longer supported.
 
Why then is there a reference to EoL here?
What is it that you actually want to know?

FreeBSD is a professional open-source OS. Users expect to know in advance some basic properties about its support and development cycles: FreeBSD is continuously being improved and further developed. Planning ahead where possible is important.

Resources are not infinite. FreeBSD has its own development and support cycles; these are not the same as most other Unix-like OS-es. FreeBSD has a support and development cycle for its base as a fully functional complete OS, and it has a different support and development cycles for everything from the ports tree such as packages.

More information can also be found in LTS support and version clarifications.

For more than a year ago FreeBSD has announced a change in its development and support cycle, an important change is the shortening of its support for a main branch, that is FreeBSD 14, 15 etc.: it will be changed from 5 to 4 years. This is a change in order to adapt more quickly and introduce improvements on the basis of shorter update cycles (see Change to FreeBSD release scheduling and support period, 11 Jul 2024 from Colin Percival*)

Another change that is significant, is the official introduction and full support for pkgbase as the binary update management mechanism for the FreeBSD base install starting with FreeBSD 15. Colin Percival explained this is at BSDCan 2024, June 2024: The Accidental Release Engineer By: Colin Percival

___
* Edit: added ref to Announce ML.
 
Last edited:
Isn't it better to use rolling releases for updates, like in Arch Linux?I like rolling because you don't have to worry about the safety of user information when switching from version to version, as you should do in non-rolling releases.
 
Isn't it better to use rolling releases for updates, like in Arch Linux?I like rolling because you don't have to worry about the safety of user information when switching from version to version, as you should do in non-rolling releases.
Then go with -STABLE or -CURRENT. EOL apply only to RELEASE.
 
Isn't it better to use rolling releases for updates, like in Arch Linux?
I think it works for apps, but OSs seem a little more tricky (I'm only aware of Arch and openSUSE for rolling).

FreeBSD having the distinction between base and packages seems to be an interesting benefit to that; the base OS itself can be kept with regular release models, but apps from pkg can be on the latest repo (instead of quarterly with the base OS schedule).

I like the idea of rolling-release, but if I understand right on FreeBSD, the OS side is CURRENT that needs compiled and updated from source (maybe comparable to Gentoo?)
 
I think it works for apps, but OSs seem a little more tricky (I'm only aware of Arch and openSUSE for rolling).

FreeBSD having the distinction between base and packages seems to be an interesting benefit to that; the base OS itself can be kept with regular release models, but apps from pkg can be on the latest repo (instead of quarterly with the base OS schedule).

I like the idea of rolling-release, but if I understand right on FreeBSD, the OS side is CURRENT that needs compiled and updated from source (maybe comparable to Gentoo?)
Building STABLE/CURRENT FreeBSD is so simple that even non dev like me can do it with ease. I've been playing with Gentoo VMs recently and it's nothing like FreeBSD, not even close.
 
Isn't it better to use rolling releases for updates, like in Arch Linux?I like rolling because you don't have to worry about the safety of user information when switching from version to version, as you should do in non-rolling releases.
FreeBSD's release cycle is far more like "rolling release" than before.

Now releases are scheduled "periodically" and release engineering cycle is to stabilize and functional as much as the schedule allows (stability and security are the first concern).

On the other hand, before switching to current release strategy, if I recall correctly, the goal for "functionality" is defined, and once the functionalities are implemented, code slush (require release engineering team [RE]'s approval for committing anything) begins and only fixes, improvements for stabilities and security are allowed, then finally, once the quality is considered OK, released. So the schedule usually delayes quite long, compared to current form.
 
Then go with -STABLE or -CURRENT. EOL apply only to RELEASE.
No, stable/13 will be EoL around April 2026 when the entire 13 major branch is retired. stable/14 will be EoL around November 2028 when the 14 major branch is retired. 15.0-CURRENT doesn't exist any more, so it's effectively EoL too.

As for the original question, 15.0-RELEASE will be EoL three months after the release of 15.1-RELEASE. Only the latest minor version of a supported major branch is supported. Previous minor versions are EoL and not supported any more.
 
No, stable/13 will be EoL around April 2026 when the entire 13 major branch is retired. stable/14 will be EoL around November 2028 when the 14 major branch is retired. 15.0-CURRENT doesn't exist any more, so it's effectively EoL too.
Please see #16
 
Isn't it better to use rolling releases for updates, like in Arch Linux?I like rolling because you don't have to worry about the safety of user information when switching from version to version, as you should do in non-rolling releases.

I would have thought it's the other way around. Any problem that might occur on a release upgrade can occur on *any* rolling release update.

In any case FreeBSD versions are only for the base system, with package you are free to do whatever you like.
 
Back
Top