Solved Is there such a thing as stable/12?

I'm currently running 12.2-RELEASE on a system that I upgraded from 12.1-RELEASE-p10. I upgraded because the news came out that there was an update available and I like to stay current (not literally current, but current as in reasonably up to date and within support windows). Before I upgraded, I got curious about when EOL would be for the 12.1 line. I visited the Supported FreeBSD Releases section of the FreeBSD Security Information page at freebsd.org (https://www.freebsd.org/security/security.html#sup). Lo and behold, this is interesting. 12.1 is supported through January (latest point release plus 3 months). But then I see, stable/12 is supported through June 30, 2024, now I am no math whiz, but that seems longer than 12.2 is likely to be supported. In my mind, I figure maybe stable/12 is a figment of somebody's imagination and just refers to the 12.x line of releases, but I also figure I should ask... is there a stable/12 cd lying around that I can install and have 'supported' until 2024, or is it just a funny way of saying FreeBSD 12 will be supported until June 30, 2024 (earliest), but that only applies to the latest point release?

If I'm way off course, please just point the way back to the straight and narrow.

Thanks!
 
I take it to mean the 12.x line will be supported until June 30, 2024.

There might be a 12.6 (or whatever!) RELEASE say April 2024 and then fixes to that (STABLE) until June 30, 2024.
 
A major branch is supported for at least 5 years after its first release. Only the last minor release of a major version is supported. Previous minor releases expire three months after the release of a new minor. New (minor) releases are made from the -STABLE branches.

But then I see, stable/12 is supported through June 30, 2024, now I am no math whiz, but that seems longer than 12.2 is likely to be supported.
The plan I believe is to have a release every six months. Early next year 13.0-RELEASE will appear. After six months a 12.3-RELEASE will be made, then 6 months later 13.1, then 12.4, 13.2, etc. By the time 12 will reach its end of life 14.0-RELEASE will be available.
 
I figure maybe stable/12 is a figment of somebody's imagination and just refers to the 12.x line of releases
It is an actual version. It's definitely not imaginary:
Code:
root@molly:~ # uname -a
FreeBSD molly.dicelan.home 12.2-STABLE FreeBSD 12.2-STABLE r366617 MOLLY  amd64
root@molly:~ # freebsd-version -uk
12.2-STABLE
12.2-STABLE

I've posted this crudely drawn ASCII art before:
Code:
------------------------------------------------------------------------------------------> -CURRENT
\_ 11.0-RELEASE -> p1 -> p2 -> ..               \_ 12.0-RELEASE -> p1 -> p2 -> ...
 \_ 11.1-RELEASE -> p1 -> p2 -> ...              \_ 12.1-RELEASE -> p1 -> p2 -> ...
  \_ {..}                                         \_ 12.2-RELEASE -> p1 -> p2 -> ...
   \_ 11.4-RELEASE -> p2 -> p2 -> ...              \_ 12.3-RELEASE -> p1 -> p2 -> ...
    \                                               \
 11-STABLE                                        12-STABLE

-STABLE is branched off from HEAD (aka -CURRENT) and HEAD changes to the next new major version. From each -STABLE branch minor versions are branched off at regular intervals until it reaches its EoL.
 
It is an actual version. It's definitely not imaginary:
Code:
root@molly:~ # uname -a
FreeBSD molly.dicelan.home 12.2-STABLE FreeBSD 12.2-STABLE r366617 MOLLY  amd64
root@molly:~ # freebsd-version -uk
12.2-STABLE
12.2-STABLE

Thanks for the clear explanation. It definitely makes more sense to me now. But, why does molly show 12.2-STABLE, but my uname show:

Code:
FreeBSD SBFreeBSD 12.2-RELEASE FreeBSD 12.2-RELEASE r366954 GENERIC  amd64

How would I get it to be 12.2-STABLE... is that what I would get if I installed fresh from a 12.2 install cd?
 
How would I get it to be 12.2-STABLE...
You build it from source. As you are a new user I would recommend you stick to a -RELEASE version for now. At least until you have a better understanding of how things work. The -RELEASE versions are easily updated using binary updates with freebsd-update(8). The -STABLE versions require you to update the source and compiling it yourself. Depending on your machine this can take a few hours to complete.
 
Ah... that makes sense. Thanks SirDice and richardtoohey2! I'm not really a new user, but I'm not deep in the guts of my system that often (other than programming for fun and instruction). I've had FreeBSD running in my house since 2008ish. That said, the release model has always been opaque to me - I would read the release engineering rationales and scratch my head and wonder what were they thinking. The release-branches tree diagram along with y'all's explanation have cleared it up for me... finally. I'm not keen on hours long compiles, but I don't mind doing it if the packages are binary. If I have to build the windows systems and suchlike, I don't look forward to dayslong builds. Can you mix a source based stable system with binary packages, or once you go source, you're committed to it all the way, base system and ports? I apologize in advance if this sounds elementary. I've been doing freebsd-update and pkg installs forever.
 
If it ain't broke don't fix it! I stick to -RELEASE builds (plus freebsd-update for security & major errata) for a quiet life but got into the habit of ports which I'm trying to wean myself off (to save a few hours).
 
Funny, I just wanted to start a thread about that.

So, my 12.1-RELEASE is not RELENG and not STABLE according to the official statement. So when is its EOL?

Whenever there's a new release, I am getting headaches about this. I always think that RELEASE means "stable, ready for production use".

BTW, to give the bleeding edge dev version the name STABLE is somewhat funny. Did I get it right? STABLE = "may contain peanuts and a lot of bugs"?

Can somebody please edit the lifecycle web page that I mentioned so that Joe Average (me) can see at a glance how much time I have left to do the upgrade to 12.2-RELEASE instead of spamming this forum? ;)
 
So when is its EOL?


BranchReleaseRelease DateExpected EoL
stable/12n/an/aJune 30, 2024
releng/12.212.2-RELEASEOctober 27, 202012.3-RELEASE + 3 months
releng/12.112.1-RELEASENovember 4, 2019January 31, 2021
stable/11n/an/aSeptember 30, 2021
releng/11.411.4-RELEASEJune 16, 2020September 30, 2021
 
BTW, to give the bleeding edge dev version the name STABLE is somewhat funny. Did I get it right? STABLE = "may contain peanuts and a lot of bugs"?
It's NOT the bleeding edge dev version - that's CURRENT. That's where the peanuts and danger lies.

STABLE is "stable" - expected to work, not expected to cause any issues, will become the next RELEASE.
 
And it's all in the documentation e.g. https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html

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.

Stick to -RELEASE unless you have a reason to do otherwise.
 
It's NOT the bleeding edge dev version - that's CURRENT. That's where the peanuts and danger lies.

STABLE is "stable" - expected to work, not expected to cause any issues, will become the next RELEASE.
Actually, that's not quite correct. FreeBSD tries not to break the ABI (Application Binary Interface) during a branch life time. That means the ABI remains 'STABLE' for applications for a whole version, from the stable release to the final minor version. That's why the naming confusing some users. They expect the STABLE branch to be 'stable', but actually it isn't and it's the ABI breakage that it is referring to. However, you are correct that most users should stick with the RELEASE branch unless they have a good reason not to.
 
So, my 12.1-RELEASE is not RELENG ...
Your 12.1-RELEASE is RELENG. RELENG is the name of the security branch of a RELEASE where security or bug fixes land:

Each FreeBSD Release has an associated Security Branch. The Security Branch tags have names like releng/10.1. The corresponding builds have names like FreeBSD 10.1-RELEASE-p4.

For more in-detail information see:

 
I guess we will have this lifecycle discussion every now and then for the next years. This one has not been the first, and it will not be the last one.

If we had something like

12.2-STABLE
12.3-TESTING
13.0-DEVELOP

everything would be clear to me.
 
I appreciate the background and discussion of the "logic" behind these branches. My personal view is that something named STABLE, should be stable, as in solid, relatively unchanging, and dependable. It's no end of confusing if STABLE is considered the testing branch. Just name it TESTING if that's the case.

My current understanding is:

STABLE - initially a branch of CURRENT that becomes the main line of development that will be branched off of for the next release. Maintenance of release branches is merged back into it in preparation for the next release?

CURRENT - new feature development happens here. These features may be backported into stable, but generally, this branch will become the next stable.

RELEASE - these are branches of STABLE that are production ready. These have 3 month lifespans after a new release.

RELENG - these are patch level releases for security fixes and such (pXX releases)

TESTING is just a state of dev that is happening in STABLE prior to release?

How far off is this?
 
something named STABLE, should be stable...relatively unchanging
Well, it is. "Should be" but might not be. "Relatively unchanging" but it might. That's why it's called STABLE but not RELEASE.

If you called STABLE, TESTING, then I can see people still getting confused about what CURRENT is. "Why isn't CURRENT called TESTING cause isn't that what you're doing?!" TESTING will always have test code inserted into it but that branch, with all hope, should contain code that will become RELEASE without changes. The only "testing" part is to see if it is stable, not testing to see if code works. Testing to see if code works is what the currently worked on version is for.

I understand your point but it's been this way for decades and easy to learn. Once you learn it, you know it, and you're done.
 
On paper RELEASE is more stable, in practice STABLE is the better choice, now days barely any patches, and not even all security fixes make it back to existing RELEASE.

However if you doing binary updates then you must use RELEASE, if you want to use STABLE then read up on the buildworld process to build it yourself.
 
in practice STABLE is the better choice, now days barely any patches
There are almost daily commits to -STABLE. Some days even a LOT of commits.


and not even all security fixes make it back to existing RELEASE.
I doubt that. Note that a bug or feature fix doesn't necessarily equate to a security issue. Do you have an example of such a security issue that wasn't fixed in a supported -RELEASE?
 
There are almost daily commits to -STABLE. Some days even a LOT of commits.



I doubt that. Note that a bug or feature fix doesn't necessarily equate to a security issue. Do you have an example of such a security issue that wasn't fixed in a supported -RELEASE?
Not off hand no, I stopped using RELEASE a long time ago, on the patches comment, I meant there is barely any patches for RELEASE.
 
I meant there is barely any patches for RELEASE.
Oh, right. Yes. Thankfully security issues are far and few in between. That said, if there are security issues they are usually fixed fairly quickly.
 
Back
Top