Explain the difference between FreeBSD's CURRENT, STABLE and RELEASE branches, and what the trailing "-p6" in a version string such as 14.1-RELEASE-p6 tells you.

## The three branch kinds **CURRENT** is the tip of development — the `main` branch of the `src` repository. Everything new lands here first. It is expected to be unstable at times, its kernel interfaces move, and running it in production is a decision to debug the operating system as part of your job. Its version string looks like `15.0-CURRENT`. **STABLE** is a `stable/N` branch, one per major version (`stable/14`). It is created when a major version is being prepared and then lives for years. Changes are developed on `main` and *merged from current* into it — the project's long-standing term for this is MFC. What "stable" promises is not an absence of bugs but **interface stability**: the kernel binary interface and the userland ABI do not break within the branch, so a kernel module or a third-party binary built against 14.0 continues to work on 14.2. Its version string looks like `14-STABLE`. **RELEASE** is a tagged snapshot. When a point release is prepared, a `releng/14.1` branch is cut from `stable/14`, stabilised, and tagged as `14.1-RELEASE`. This is the artefact everything downstream targets: the installer images, `freebsd-update`, and the binary package repositories, whose ABI string identifies the major version and architecture in the form `FreeBSD:14:amd64`. The flow is one-directional: `main` → `stable/14` → `releng/14.1` → `14.1-RELEASE`. ## The -p number After a release ships, the security team publishes Security Advisories and the release engineers publish Errata Notices. Each applied set increments the patch level, so `14.1-RELEASE-p6` means six such rounds have been applied to that release. `freebsd-update fetch install` is what moves it. The patch level is the number you compare against an advisory to answer "am I vulnerable?", so it belongs in your inventory alongside the release number. ## Reading the version on a live machine This is the practical half of the question, and it catches people out: ```sh uname -r # the RUNNING kernel only freebsd-version -k # the INSTALLED kernel freebsd-version -r # the RUNNING kernel freebsd-version -u # the USERLAND ``` Right after `freebsd-update install`, the installed kernel and the userland can show a new patch level while the running kernel still shows the old one — because you have not rebooted. `uname -r` alone will happily tell you that you are still unpatched, or (after a reboot) that you are patched when a userland patch has not been applied. Checking the kernel and userland separately is how you verify that a patch round actually landed. ## Which branch should you run? For almost every production system: RELEASE, kept at the current patch level with `freebsd-update`. You get binary base patches, binary packages built for your ABI, and a supported upgrade path. Run STABLE only when you need a fix or a driver that has been merged but not yet released, and accept the consequence: **`freebsd-update` serves only RELEASE branches**, so a STABLE machine is a from-source machine — `buildworld`, `buildkernel`, `installkernel`, `installworld`, plus an `etcupdate` merge. That is a real, recurring operational cost per host, and it is the reason most shops that need a STABLE build produce their own images or their own binary update stream rather than compiling on each server. CURRENT is for developers and testers, not for servers. ## Support windows The support model since the 13 series works on two clocks: a `stable/N` branch is supported for roughly five years from its first release, while an individual point release stops receiving patches a few months after its successor appears. The practical consequence is that staying on 14.1 forever is not an option even though the 14 branch is supported for years — you must keep moving to the newest point release within the branch to keep receiving `freebsd-update` patches. A major-version upgrade (`freebsd-update -r 15.0-RELEASE upgrade`) is a bigger event that also requires reinstalling packages built for the new ABI. ## Interview framing The grader wants three things: that you can order the branches correctly and say what STABLE actually promises (interface stability, not reliability); that you read the `-p` level as patch state rather than a version; and that you know binary updates and binary packages are RELEASE-oriented, so choosing STABLE is choosing to build from source.