LTS support and version clarifications

[Cath O'Deray]

3 major versions for FreeBSD:
12.x [stable]
13.x [stable]
14.x [current]

Not just STABLE. Please see for example:

Versions 12.x and 13.x are versions that you can install.
Version 14.x it's being developed and tested.

FreeBSD 14.0-CURRENT can be installed.

STABLE is more difficult to update than RELEASE.

12, 13 and 14 are developed and tested.

5 years

At least.

{link removed} (2015-02-03) ◀ <{link removed}>

 

[freebuser]

To jump in and try my part to put it in a simpler way

One thing to remember is CURRENT and STABLE branches are continuous development branches.
So, a snapshot from CURRENT will become a STABLE branch with then the CURRENT continue its development.
The STABLE branch will continue its separate development until a snapshot is released as a -RELEASE version. The -RELEASE version does not get developed any more and it is the final destination for that release.
But, the STABLE branch still continue in development and another snapshot is made for the next -RELEASE version.

With this the sketch will be more clearer to understand.

Hope this helps.

The understanding of that the CURRENT and STABLE branches are continuously developed I too had difficulty in understanding the branching of FreeBSD, but it all makes sense once understood.

 

[decuser]

As the 13.1 releng branch nears release, I was curious when EOL for 12.3 was, after scratching my head a bit trying to remember the difference between monikers and being momentarily befuddled by the Stable 12 is supported through 2024 even though I'm pretty sure stable is the dev branch and the stable branches are really the releng's along the way, I came back here to get it all straight in my head again. Sheesh! Major - minor really isn't the devil. Just name dev, dev, do the major minor thing and be done with it.

 

[SirDice]

I was curious when EOL for 12.3 was

12 will be supported until at least 2024. So it's likely a 12.4 will be released. 12.3 will be EoL three months after the release of 12.4. That 12.4 is probably the last release of the 12 branch. It will most likely be EoL some time after the release of 14.0.

and being momentarily befuddled by the Stable 12 is supported through 2024 even though I'm pretty sure stable is the dev branch and the stable branches are really the releng's along the way,

It's just to indicate the predicted end of the entire 12 branch.

 

[blackhaz]

I was also extremely confused by the naming and still do not understand why FreeBSD is sticking with it, unless FreeBSD developers want to emphasize the system is created for developers, but not end users. I guess there should be a note somewhere in bold red: "Branch naming here is for the developers, not end users. Stick with the RELEASE, peasant!"

End users expect something called "stable" to be stable, maybe with long-term support, but definitely production-ready. You generally expect stable servers not to loose user data. Never under any circumstance end user expects a development branch to be called "stable".

End users expect something called "current" to be the latest stable version. It's current, but we assume that developers took care to assure the quality of the current version before releasing. Never "current" suggests to us that something is not designed for use at all.

Would developers be hurt if STABLE is renamed to DEVELOPMENT, and CURRENT to FUTURE?

(Disappears in smoke.)

 

[Alain De Vos]

It's a freebsd tradition. Once you get used to it. Never mind. There is current,stable,release.

 

[Criosphinx]

"End users" meaning Linux users.

Never had a problem with the names, the Download page at freebsd.org explains everything.

 

[PMc]

I was also extremely confused by the naming and still do not understand why FreeBSD is sticking with it, unless FreeBSD developers want to emphasize the system is created for developers, but not end users. I guess there should be a note somewhere in bold red: "Branch naming here is for the developers, not end users.

Yes, and this is deliberately so, because BSD has a tradition that reaches back, back to the very beginning.

The idea that there would be a difference, at all, between so-called "developers" and anybody else, is much newer. It wasn't there in the 80s, it wasn't there in the 90s. If you were able to run a computer and install an OS, you were part of the thing, and there was no discrimination, no labels attached to people.

That is also why we usually have the full source code installed, everybody can read it, and everybody can actually build from it; there is no magic involved, it is all scripted.
Was it J.Beuys who said, everybody is an artist? So I say, everybody is a developer, and finished.

BTW, I'm always wondering: was it the "developers" who shut themselves into an ivory tower, or was it the people who declared themselves not wanting to be developers, and wanting to be spared from thinking and understanding?

End users expect something

"End users" is bogus. Go back only hundred years (2 1/2 generations), and there was practically nothing a village would need that they could not make by themselves.

This is the essential point: having no idea about how the stuff works that you have in your hands, is the most dangerous thing that can happen to a civilisation. Look at civilitations and see where too much abstraction has brought them: look the Egypt, look the Maya, look the Roman Empire, look the Europeans (very soon).

 

[Andrey Lanin]

If you were able to run a computer and install an OS, you were part of the thing

Linux was like that in the mid 90s. Remember Slackware? Each of us flipped through the pages of the installer for half an hour, choosing which daemons should be launched and which software to install, analyzing dependencies, each of us first configured, and then executed 'make World' and waited for several hours to complete ...Those were the good times when you were in control of what you worked with.

 

[zirias@]

I was also extremely confused by the naming and still do not understand why FreeBSD is sticking with it, unless FreeBSD developers want to emphasize the system is created for developers, but not end users.

This would only be true if you insinuate only developers would ever read documentation.

The term "release" is well-known and certainly doesn't require special knowledge. So once you look for available downloads, see -RELEASE versions first and recommended and then, you see there's also -STABLE, how in the world would you ever conclude to just install that? If you really think "wait, isn't that the same?", wouldn't you just read the few sentences on FreeBSD pages that explain how it's a version under development?

BTW, at work, we adopted a similar branching scheme (main/stable/release) for an internally shared project, because this works really well. We did one little naming change though: "stable-api" instead of "stable", to avoid this little confusion for people who don't read the docs first. Still, the word "stable" is extremely important here. This scheme is working so well because APIs/ABI don't change on that branch, which guarantees seamless minor upgrades and simple merging of security fixes to the release branches.

End users expect something called "stable" to be stable, maybe with long-term support, but definitely production-ready.

And about this, what's "production-ready" is ultimately up to you to decide. A classic release engineering can guarantee the best quality, so that's recommended for production. Still, stable is "stable". Only compatible changes (read: no breaking changes) are ever merged to stable, and only after some testing period on main (-CURRENT). So, if you'd ever consider e.g. some rolling-release Linux dist (where the base components are continuously updated as well, and don't even care for breaking changes) "production-ready", FreeBSD -STABLE is as well.

 

[kpedersen]

I was also extremely confused by the naming and still do not understand why FreeBSD is sticking with it, unless FreeBSD developers want to emphasize the system is created for developers, but not end users.

Linux doesn't do this and yet still seems to be unsuitable for end users as demonstrated with its <1% market share. So why do you really want to break existing knowledge for the sake of... who exactly?

 

[decuser]

It’s December 2022 and 12.4’s been released. Which one’s which again?, oh yeah just need to reread this thread clarifying the purportedly clear already nonsense . Definitely not stable, or current, I guess that leaves release... wait, not so fast, prolly want a release snapshot if I really want a stable os

Will

 

[bakul]

See https://www.freebsd.org/security/#sup --12.4 will likely be EOLed at the end of 2023. [On this page there is a typo in the release date for 12.4 but the rest is fine]

In general point release X.Y is supported for 3 months *after* X.Y+1 is released. Even though branches are named stable/12, stable/13, etc/ they are *less* stable than the point releases but usually more stable than -CURRENT (the *main* branch in the git repo).

My advice: unless you have a strong reason to prefer a stable branch, stick to a point release. Don't be thrown off by a shorter EOL period for them. As long as you continue updating to newer point releases you are fine.

 

[anlashok]

2022 update

 

[PMc]

It's not so difficult. If You're free to choose, choose a RELEASE, and choose an x.1 or x.2 that is available - that's what most people are using at the given time, and what leaves you with the most options and can stay stable for another 3-4 years.

 

[chrislongros]

So right now is 12.4 or 13.1 the latest stable release?
12.4 was released on December 5th and 13.1 was released on May 16th and has various patches
For example if I want to try a system with the latest Open ZFS version should I install 12.4 or 13.1?

 

[Erichans]

Look at the picture above at message #64 and at Supported FreeBSD releases: there is no indication of a minor version of a stable branch (something like 12.y-STABLE) in the version control system, and because of that there are no FreeBSD-STABLE minor versions*: no 12.4-STABLE and no 13.1-STABLE. The most tested and production ready are the FreeBSD x.y-RELEASE versions (x being the major version number and y being the minor version number).

ZFS is included with FreeBSD**. FreeBSD 12-STABLE and all FreeBSD 12.y-RELEASE-s are based on a ZFS version pre-OpenZFS. As of FreeBSD 13, FreeBSD comes with OpenZFS.

[...] For example if I want to try a system with the latest Open ZFS version should I install 12.4 or 13.1?

To try a supported FreeBSD version with the latest OpenZFS included, I suggest you install FreeBSD 13.1-RELEASE.

(Based on what you wrote, I see no compelling reason or advantage to use 13-STABLE by using either a snapshot or building it yourself; see also the FreeBSD Handbook and other Documentation as displayed here)

___
* If you use the source code from the FreeBSD git repository, for say FreeBSD 13-STABLE, to build your own system you'll get the latest code of the 13-STABLE branch (note: "-STABLE" refers to the ABI (=Application Binary Interface) being stable).
** FreeBSD can use a different OpenZFS kernel module by specifying that in /boot/loader.conf (see: OpenZFS-Home » Getting Started » FreeBSD). As for OpenZFS development versions, you can also use sysutils/openzfs-kmod (kernel module) & sysutils/openzfs (userland).

 

[chrislongros]

Thanks for the response. I understood the versioning system, I meant point releases

 

[SirDice]

People down here have a different understanding when you talk about 'stable' or 'current' versions. Those have a specific meaning with FreeBSD.

So right now is 12.4 or 13.1 the latest stable release?

All releases are stable (i.e. their fitness to run reliably).

For example if I want to try a system with the latest Open ZFS version should I install 12.4 or 13.1?

OpenZFS is included with 13.0 and higher.

 

[Zare]

As an user, you're to use -RELEASE, and freebsd-update fetch/install regurally. If you do that, you'll always have a fresh minor release of your FreeBSD version, keeping you up to date with actual major version of FreeBSD (13.0, 13.1, etc...). If you do that, you'll have years of support.

FreeBSD naming comes from the FreeBSD development. STABLE is from developer mindset. It is CURRENT code that seems stable enough for further testing; alpha code of the future release.

Have a simple CI/CD process in a development team; rolling dev branch, gets merged to test branch, gets tested out and promoted to release. Customer has access to release repository.

But FreeBSD is an open source project, it has no definition of developer vs customer, it's all for people. So you get access to the all the branches.

From that viewpoint it would be only helpful to denote in the documentation in big letters, if you're not an enthusiast, tester, developer, hardware integrator, you're unlikely to require anything but RELEASE.

FreeBSD gains traction when Linux users get annoyed by their distributions and then they try FreeBSD. Keep in mind that average Linux distribution is far more user friendly than FreeBSD requiring far less knowledge about anything computers. So some new users will not be coming from 'developer' mindset but more from "Windows power user" perspective, because this is where those distributions pick up their market from.

It also doesn't help that some sources are outdated and recommend -STABLE to have latest user packages, not aware of the quarterly pkg.

 

[PMc]

Nicely explained, Zare - but You look only at the developers and the users. You didn't mention another party involved: the stakeholders.

For a stakeholder a change is a dangerous thing. It may break other things, in an unforseeable way. And then certain processes may not work as intended. And then they may loose money. That's what the "LTS" thing is all about.

For me, this is not an issue, as long as I have the source and can fix the broken things myself (my installation has dozens of local patches, because of this). But a stakeholder does not consider this a viable path, because it requires skill.

As You write Yourself...

is far more user friendly than FreeBSD requiring far less knowledge about anything computers.

... nowadays it is considered a "feature" to not require knowledge. And I think this is bad.

 

[Zare]

Nicely explained, Zare - but You look only at the developers and the users. You didn't mention another party involved: the stakeholders.

In this analogy the stakeholders would be big clients/donors and AFAIK they have no qualms with FreeBSD naming.

I haven't heard Sony having problems with syncing the Playstation system software with upstream FreeBSD nor I heard Netflix having issues in deploying FreeBSD servers.

Because FreeBSD has long term support in the sense of that phrase, regardless of not having a such a tag in its nomenclature.
A stakeholder that doesn't understand the release process of the product is well out of his league.

Here we're talking about ordinary users understanding one way and one way only, while there is no single right way to do release engineering. The product doesn't have to have a declared "LTS" version in order to be viable for long term integration. It's all about a particular process.

 

[PMc]

In this analogy the stakeholders would be big clients/donors and AFAIK they have no qualms with FreeBSD naming.

Well, in the simple case, the stakeholder is the person who gives you the paycheck, and whom you try to convince that they might run FreeBSD (instead of Linux/Windows/whatever) in the shop where you work.

 

[Zare]

Well, in the simple case, the stakeholder is the person who gives you the paycheck, and whom you try to convince that they might run FreeBSD (instead of Linux/Windows/whatever) in the shop where you work.

Then it's up to you to know what branches will be supported

In any case main impediment of introducing FreeBSD to a commercial project is not the lack of support from the FreeBSD project but lack of FreeBSD staff in work market as compared to Linux. I've recommeded FreeBSD several times, the management will reply they are aware of the benefits but "who is going to work on it if and when you leave the company".

Also doesn't help that a lot of companies are moving to instances and containers, and Openshift doesn't run FreeBSD. The company I currently work for doesn't care much about what Linux is installed on the developer's PC, we have default, but it can be anything we support in terms of hardware, because the projects run in containers.

 

[Cath O'Deray]

There's a five-year policy.

14.0-RELEASE is recommended for new deployments.