LTS support and version clarifications

[Cath O'Deray]

… not inline with, and even clashes with, the FreeBSD website, …

… FreeBSD website information inline with the Handbook, …

… From the above Handbook quote: … contradiction with: …

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

… FreeBSD Support Model. …

Re: clashes and contradictions in documentation and elsewhere, please see:

<link removed>

 

[anlashok]

Farewell 12, you served us well.

 

[Cath O'Deray]

anlashok thanks. Three corrections/suggestions:

1. support for STABLE (not for RELEASE alone) – important
2. uppercase for CURRENT, STABLE, RELEASE (but not for branches e.g. stable/14 (stable/15 does not yet exist))
3. add 13.5-RELEASE, 14.5-RELEASE, 14.6-RELEASE, 15.5-RELEASE, 15.6-RELEASE.

An alternative to the pictured proposal includes 13.6-RELEASE and 14.7-RELEASE. I shouldn't include those.

 

[anlashok]

3. add 13.5-RELEASE, 14.5-RELEASE, 14.6-RELEASE, 15.5-RELEASE, 15.6-RELEASE.

The last major release with a point release greater than .4 was FreeBSD 5.5 over 17 years ago, so aside from the screenshot you shared it doesn't strike me as a needed change to this image quite yet. Quite easy to do though I can just rename the release arrows text in the SVG so that every row shifts up two rows (i.e rename x.0 to x.2 etc.) as if there is a .5+ then there is no need to refer to the .0 or .1 releases as they would be long EOL by then.

Regarding STABLE being supported, is this not implicit for any version with a supported RELEASE version on the same branch?

 

[SirDice]

The last major release with a point release greater than .4 was FreeBSD 5.5 over 17 years ago, so aside from the screenshot you shared it doesn't strike me as a needed change to this image quite yet.

Agree, with the current pace of releases a .4 is typically the last minor version of a major branch.

 

[Cath O'Deray]

… implicit …

It's explicit – "… each major version’s stable branch is explicitly supported for 5 years, …".

 

[Cath O'Deray]

with the current pace of releases a .4 is typically the last minor version of a major branch.

I haven't listened to everything from all four days, but I do like the proposed changes. Support for three stable branches should become a rarity, and so on.

I can't imagine no change; we should expect an announcement in due course.

 

[Cath O'Deray]

Support for three stable branches should become a rarity,

allanjude@ I guess, it was you in the audience, "… Three total branches including main is probably the cap of what we can stomach …".

+1

 

[Erichans]

The last major release with a point release greater than .4 was FreeBSD 5.5 over 17 years ago, so aside from the screenshot you shared it doesn't strike me as a needed change to this image quite yet.

Agree, with the current pace of releases a .4 is typically the last minor version of a major branch.

+1 (twice)—I think in the (SVG) picture we should focus on what's relevant for the user at this moment and leave any distant projections not in view for what they are: not in view.

 

[Cath O'Deray]

… distant projections …

What might be treated as distant?

(2028 is implicit in the section below.)

 

[USerID]

I can't figure out (how/when) "nodes" (11, 12, 13, 14...) are formed on the CURRENT branch? For example, I recently installed the "15-CURRENT" slice on my PC. I updated now. But if I update, for example, in 4 years, then "WHERE" will I be:

1. in the same version 15-CURRENT?
2. in version 15.4-CURRENT?
3. in version 16-CURRENT?

After WHAT time will the CURRENT branch show a label ("node") of version 16? After 4 years? Correct?
I read that the minor version changes every 3 months, and the major version now changes every 4 years (and not 5 years as before).

And I also wanted to ask: if I regularly update today's CURRENT (starting with 15.0) every 3 months, does that mean that I will have a permanent "seamless" a la "rolling release" (in Linux terminology)? And then I won't need to go through the stages of transitions from 15.0 to 15.1, then 15.4 to 16.0, etc.? For me, it will be, in some way, transparent? Thank you!

 

[Jose]

I can't figure out (how/when) "nodes" (11, 12, 13, 14...) are formed on the CURRENT branch? For example, I recently installed the "15-CURRENT" slice on my PC. I updated now. But if I update, for example, in 4 years, then "WHERE" will I be:

How do you "update", git pull? If so...

1. in the same version 15-CURRENT?

Almost certainly not. The 15.0 release is targeted for a year from now. At that point the main branch, and therefore -CURRENT will become Freebsd 16.

2. in version 15.4-CURRENT?

Same as 1.

3. in version 16-CURRENT?

There's no way to tell since it depends on the pace of releases, and that varies sometimes. Eyeballing the .0 releases here, it seems there are about two years between major releases. Four years from now is December 2028. If 15.0 goes off on time in December 2025 and then 16.0 is released in December of 2027, The main branch would be 17-CURRENT at that point. There are no guarantees, however. For example, the Openssl "upgrade" delayed the 13.0 release, as you can see from the directory listing of old releases.

After WHAT time will the CURRENT branch show a label ("node") of version 16? After 4 years? Correct?

It's not a set amount of time. It happens whenever a new major .0 version is released.

I read that the minor version changes every 3 months, and the major version now changes every 4 years (and not 5 years as before).

And I also wanted to ask: if I regularly update today's CURRENT (starting with 15.0) every 3 months, does that mean that I will have a permanent "seamless" a la "rolling release" (in Linux terminology)?

You are likely to encounter lots of problems. It's a development branch, and often has bugs that break it and/or whatever ports you have installed on your system.

And then I won't need to go through the stages of transitions from 15.0 to 15.1, then 15.4 to 16.0, etc.? For me, it will be, in some way, transparent? Thank you!

No. Your system will suddenly become 16-CURRENT and will likely need lots of manual intervention to keep everything copacetic.

The last major release with a point release greater than .4 was FreeBSD 5.5 over 17 years ago...

Ironically, there's going to be a 13.5 release. You jinxed yourself! Anyways, thanks so much for these excellent graphs.

 

[T-Aoki]

After WHAT time will the CURRENT branch show a label ("node") of version 16? After 4 years? Correct?

It is updated when new stable branch is created.
The version name is specified in /usr/src/sys/conf/newvers.sh.
For main (aka CURRENT) branch, https://cgit.freebsd.org/src/tree/sys/conf/newvers.sh. See REVISION= and BRANCH= lines.
And main branch became 15.0 at 2023-08-24 23:10:35 +0000 with commit aee253d8a7aea40189f8ca74138d6bed10948b1e.

See (already finished) schedule for 14.0-Release for details.

When new stable branch is created, main becomes ALPHA[1|2|...], and once it is considered to be worth BETA grade, new stable branch (this time, stable/14) is created and main is bumped with being marked again as CURRENT.

BETA are built from new stable branch, and once it is considered as RC-ready, new releng branch (here, releng/14.0) is created.

RCs are built from new releng branch, and when it is considered as Release-ready, finally Release build is done and the releng branch is turned over from Release Engigneering team to secteam.

Following patch releases like 14.0-p1 are built from the releng branch. Basically, only bug fixes and security upgrades are allowed by secteam on releng branches after its first release is done.

Point releases like 14.1 and 14.2 are branched from the same stable branch. Stable branches are marked as BETA at the start of new release cycle (no ALPHA, as stable branch is considered to be already passed the phase), and the same are done (but from BETA) as *.0-Release, and back to STABLE once new releng branch is created.

 

[SirDice]

Point releases like 14.1 and 14.2 are branched from the same stable branch. Stable branches are marked as BETA at the start of new release cycle (no ALPHA, as stable branch is considered to be already passed the phase), and the same are done (but from BETA) as *.0-Release, and back to STABLE once new releng branch is created.

X.(Y+1)-PRERELEASE, it goes from 14.0-STABLE to 14.1-PRERELEASE, then releng/14.1 is branched off and it returns to -STABLE, 14.1-STABLE (the version doesn't change).

14.0-STABLE -> 14.1-PRERELEASE
releng/14.1 branched off, 14.1-BETA1
14.1-PRERELEASE -> 14.1-STABLE
{lot of work on stable/14 as 14.1-STABLE}
14.1-STABLE -> 14.2-PRERELEASE
releng/14.2 branched off, 14.2-BETA1
14.2-PRERELEASE -> 14.2-STABLE[/file]

 

[USerID]

Ok, thanks!

 

[lepharaon33]

Hello everybody,
I have read the documentation for a while but have not been able to clarify my doubts.
I will try to be as short as possible.
At present according to this table: https://www.freebsd.org/security/#sup the latest LTS version is Stable 12.
So if I wanted to have a long support I don't have to update for example at 12.2 so just do a package updates.
It's correct?
Finally, I still don't understand the difference between Stable and Release.
Does the Release then become stable and then once stable LTS at least this for the major versions?
Instead, the minor versions remain in the release state?

You’ve got most of it right, but here’s a bit of clarification.

• RELEASE versions (like 12.4-RELEASE) are the officially published snapshots of FreeBSD intended for general use — production systems, servers, etc.
• STABLE branches (like 12-STABLE or 13-STABLE) are ongoing development branches where bug fixes and some new features are merged after testing. They’re generally reliable but not as “frozen” as RELEASE.

When a new RELEASE is cut from a STABLE branch, it becomes a fixed version that gets security and critical updates for its support lifetime.


If you want long-term support, you should stick with the latest RELEASE version of the major branch that still has security updates — for example, 12.4-RELEASE if it’s still supported according to the FreeBSD security page. You don’t need to track 12-STABLE unless you specifically want newer fixes or features before the next RELEASE.