LTS support and version clarifications

[thedaemon]

I have a question related to this.

• What does "Supported" mean in this case?
• What kind of support?
• Who gives the support?

It's not a paid product, so I'm not really sure how the "support" works.

 

[cracauer@]

I have a question related to this.

• What does "Supported" mean in this case?
• What kind of support?
• Who gives the support?

It's not a paid product, so I'm not really sure how the "support" works.

Fixes are coming for those versions that are under support.

 

[bakul]

It means for M.N releases, security fixes.
For stable/M branches, vetted changes go in from the HEAD branch.
Anyone can file bug reports. Critical bugs get fixed but others may/may not get any attention
After EOL of a branch there is no support, not even security patches.

 

[anlashok]

14.0 Release Update

 

[grahamperrin]

I'm not really sure how the "support" works.

There's a five-year policy.

14.0-RELEASE is recommended for new deployments.

<https://www.freebsd.org/security/#model> – the FreeBSD support model

Second paragraph:

The details and rationale behind this model can be found in the official announcement sent in February 2015.

Re: the dates at <https://www.freebsd.org/security/#sup>,

273795 – Correct the expected end of life for stable/13; add stable/14 and 14.0-RELEASE

bugs.freebsd.org

• reportedly fixed
• not yet fixed, the published date for stable/13 is wrong.

 

[thedaemon]

<https://www.freebsd.critialorg/security/#model> – the FreeBSD support model

Second paragraph:



Re: the dates at <https://www.freebsd.org/security/#sup>,

273795 – Correct the expected end of life for stable/13; add stable/14 and 14.0-RELEASE

bugs.freebsd.org

• reportedly fixed
• not yet fixed, the published date for stable/13 is wrong.

This does not define support. It just says "support" it doesn't define support.

bakul answered it I think: Security patches. That's it, that's all support means. Security patches.

 

[grahamperrin]

That's it, that's all support means. Security patches.

Not only security. From the announcement:

These changes to the FreeBSD support policy will reduce turnaround time for security advisories and errata notices, provide binary package sets that are more closely aligned with the latest FreeBSD release from a given branch, and clearly define the minimum length of time that a branch will receive support.

 

[grahamperrin]

14.0 Release Update

Thanks, this type of visualisation is popular, however it's a misrepresentation of what's supported.

 

[SirDice]

Thanks, this type of visualisation is popular, however it's a misrepresentation of what's supported.

It wasn't meant for that. It's to explain the relationship between the various versions and branches, because this often trips up new users.

 

[T-Aoki]

API(Application Programming Interface)/ABI(Application Binary Interface) and/or KPI(Kernel Programming Interface)/KBI(Kernel Binary Interface) could be changed even on RELEASE (releng) if any vulnerabilities cannot be fixed without API/ABI and/or KBI/KPI changes. So keeping attention to UPDATING is mandatory.

 

[bakul]

Has this ever happened?

 

[grahamperrin]

It wasn't meant for that. It's to explain the relationship between the various versions and branches, because this often trips up new users.

If my footnote at <https://forums.freebsd.org/posts/564808> is correct, the image first appeared at <https://forums.freebsd.org/posts/506851>.

The red rectangles should not be for RELEASE alone.

From a PR for the download page:

With added emphasis:

… Errata notices and security advisories: cover releases and associated stable branches …

(man:freebsd-update[8], in the screenshot, is code for freebsd-update(8).)

---

I am, of course, completely ignoring the many problems with my own imagery (the ASCII art)

 

[grahamperrin]

… keeping attention to UPDATING is mandatory.

+1

I'd extend that, to two UPDATING files (the one for base and the one for ports).

 

[T-Aoki]

Has this ever happened?

Not precisely remember, but if I recall correctly, something alike happened to support something (in ports) updated mandates.
And security should take precedence to compatibility. For me, it's basically only thing to be ALWAYS AT ANY TIME allowed to break API/ABI/KPI/KBI compatibility even on single releng branches.

Similar but not breakage (addition of new functionality), years ago, some functions in kernel, which some people disliked, was introduced to keep getting support for nvidia GPUs by x11/nvidia-driver*, if I recall correctly.
These kind of things is not assured not to break KBI/KPI. These are on grey zone.

 

[T-Aoki]

I'd extend that, to two UPDATING files (the one for base and the one for ports).

Of course. Both are mandatory.

 

[grahamperrin]

…  this naming convention is highly confusing: The thing that is stable (adjective) is the kit that is called RELEASE (noun). The thing called STABLE (noun) is not stable (adjective). … 

STABLE is stable.

Quoting Colin Percival in Reddit:

13-STABLE is a production branch, from which a production release will happen once testing is complete. ;-)

Some people run -STABLE in production. Heck, some people run -CURRENT in production. Different risk appetites...

Cc gtewallace

 

[Erichans]

I really don't understand the insertion of this message with the quote in this thread. What is the source link of the quote?

[...] STABLE is stable.
Quoting Colin Percival in Reddit:

13-STABLE is a production branch, from which a production release will happen once testing is complete. ;-)

Some people run -STABLE in production. Heck, some people run -CURRENT in production. Different risk appetites...

This certainly is not inline with, and even clashes with, the FreeBSD website, Get FreeBSD:

Development and Testing​

Pre-RELEASE versions of FreeBSD, not intended for use in production environments:

• CURRENT – the main branch, the core of development
  
• STABLE – branched from CURRENT, long-term preparations for release engineering
  
• release engineering – ALPHA, BETA, release candidates (RC) – branched from STABLE.

Uppercase has special meaning. For example:

• a first beta release is not a (production) RELEASE.

FreeBSD-STABLE is defined and designated as stable because it has a stable ABI. Based on various impressions over the past few years by others more experienced than me, IIRC, FreeBSD-STABLE, in its contemporary state, is a more coherent and "stable" code base for running FreeBSD compared to what it was in the past. Note that, as even "a first beta release is not a (production) RELEASE", the obvious conclusion is that -STABLE is not "of production quality"—just as its heading states.

Furthermore, I find the FreeBSD website information inline with the Handbook, 26.5.2. Using FreeBSD-STABLE:

FreeBSD-STABLE is the development branch from which major releases are made. Changes go into this branch at a slower pace and with the general assumption that they have first been tested in FreeBSD-CURRENT. This is still a development branch and, at any given time, the sources for FreeBSD-STABLE may or may not be suitable for general use. It is simply another engineering development track, not a resource for end-users. Users who do not have the resources to perform testing should instead run the most recent release of FreeBSD.

Note that this is part of the chapter 26.5. Tracking a Development Branch.

From the above Handbook quote: "[FreeBSD-STABLE] is still a development branch"; this is in contradiction with:

13-STABLE is a production branch, from which a production release will happen once testing is complete. ;-)

as attributed to Colin Percival.

If you or Colin Percival feel that FreeBSD-STABLE should be designated otherwise, I strongly suggest: change all documentation accordingly.

Without any context about suggesting running -CURRENT in production* ("Heck, some people run -CURRENT in production. Different risk appetites..."), I hardly find this helpful for any newcomer to FreeBSD trying to choose between -RELEASE, -STABLE or -CURRENT and, while reading this thread, trying to understand how these are related to the FreeBSD Support Model.

___
* There may even be professionals who run a very monitored, specifically tailored version of -CURRENT in production; professionals that are almost certainly in the category of highly skilled & professional FreeBSD developers who know how to turn a specific state of a -CURRENT code snapshot into a workable, reliably running set of binaries. And, probably even more important, how to maintain a reliable system when injecting specific, selected code upgrades. However, I do think that that is hardly an appropriate topic for this thread.

 

[blackhaz]

So, yes, it's called BUTTER, but it's actually not. It's milk. It's just butter not of the production quality yet. We make butter whenever we can, sometimes fast, sometimes slow, so it's butter in development that may or may not be suitable for general use. It's simply another process of pasteurization, maturation, churning and blending in the making. Users who do not have the resources to make sure it's really butter without unpackaging and tasting it should instead buy the most recent brick of butter. Although BUTTER is actually milk, it's a production branch, which will really become butter once all the butterfat will be crystallized, drained, washed, salted and packaged.

 

[grahamperrin]

blackhaz RELEASE cow:

• sincerely welcomes the dairy metaphor
• has no thumb, offers a hoof-up, which translates to a thumbs-up from me.

 

[grahamperrin]

What is the source link of the quote?

 ______________________________________________________________
< https://old.reddit.com/comments/18slzge/-/kfagos2/?context=1 >
 --------------------------------------------------------------
        \   ^__^
         \  (..)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

 

[zirias@]

So, yes, it's called BUTTER

Perfect example for the fact that comparisons almost always go wrong. Issue here: I'm not aware of any context dependent meanings of "butter".

The issue some people have with "STABLE" on the other hand is implying the wrong meaning: as in "the system will run without issues", which isn't even measurable well, nevertheless was established that way by, uhm ... "some projects".

In the context of interfaces though (most importantly ABI), "stable" is clearly defined: No changes. And that (and only that) is what the name of the branch means.

 

[zirias@]

From the above Handbook quote: "[FreeBSD-STABLE] is still a development branch"; this is in contradiction with:

13-STABLE is a production branch, from which a production release will happen once testing is complete. ;-)

as attributed to Colin Percival.

Not necessarily. You could put it that way to solve the presumed contradiction: It's the branch where production releases are developed.

Yes, just calling it a "production branch", although not technically wrong (it's even listed in the support lifecycle), might be misleading people to expect it to have release quality. This isn't guaranteed. The meaning of "stable" is still what you described of course.

 

[T-Aoki]

In the context of interfaces though (most importantly ABI), "stable" is clearly defined: No changes. And that (and only that) is what the name of the branch means.

My guess is a bit different. Stable API/ABI/KPI/KBI means no deletions, no changes, but additions.

And in many cases, end users who runs current would be motivated for drivers that's not yet MFC'ed to stable (then, releng) is strongly needed for them, accepting risks.

 

[grahamperrin]

Recent commits to stable/14 include:

param.h: Bump __FreeBSD_version to 1400502 · freebsd/freebsd-src@092abb8

Commits acc704b36192 and b8e137d8d32d both modified the internal API between the kgssapi and krpc modules. As such, both of these modules need to be rebuilt from sources. I have bumped __FreeBSD_v...

github.com

param.h: Bump __FreeBSD_version to 1400503 · freebsd/freebsd-src@ba99d96

Commit 925d9b3abac2 changed the internal API between the nfscommon and nfscl modules. As such, both need to be rebuilt from sources.

github.com

Bump __FreeBSD_version for llvm 17.0.6 merge · freebsd/freebsd-src@68584c9

PR: 273753 MFC after: 1 month (cherry picked from commit c711af7727824da79d87f375f3d6829feec3799a)

github.com

 

[T-Aoki]

Recent commits to stable/14 include:

param.h: Bump __FreeBSD_version to 1400502 · freebsd/freebsd-src@092abb8

Commits acc704b36192 and b8e137d8d32d both modified the internal API between the kgssapi and krpc modules. As such, both of these modules need to be rebuilt from sources. I have bumped __FreeBSD_v...

github.com

param.h: Bump __FreeBSD_version to 1400503 · freebsd/freebsd-src@ba99d96

Commit 925d9b3abac2 changed the internal API between the nfscommon and nfscl modules. As such, both need to be rebuilt from sources.

github.com

Bump __FreeBSD_version for llvm 17.0.6 merge · freebsd/freebsd-src@68584c9

PR: 273753 MFC after: 1 month (cherry picked from commit c711af7727824da79d87f375f3d6829feec3799a)

github.com

"internal" API/KPI should not exposed to outside related components, so would happen. If the interfaces between specific modules only are defined an independent header and all modules need the interface includes it, I "feel" bumps are not needed, though. Make should handle the rebuild.

llvm/clang could be an exception, as it's toooo huge to maintain multiple versions throughout supported branch, IMHO. And multiple versions in base could cause difficulties on ports which don't want to depend on devel/llvm* ports.

Another exceptions I see is linuxkpi for drm kmods. It's still under heavy developements and causes drm kmods to fit into. But it may be the results to fix problems on drm kmods and allow supporting not-yet-working drivers. This is my guess and the reason I'm sticking with x11/nvidia-driver.