PREV_LEC | NEXT_LEC

What You Will Learn

Prerequisites

You should have git installed and roughly 3-4 GB of free disk space if you plan to clone the full mainline tree along with the lecture 1 basics of user space vs kernel space.

How Version Numbers Are Built Today

Modern mainline Linux uses a two-number scheme, MAJOR.MINOR, for example 6.9. A new minor release ships roughly every 9-10 weeks, and there is no meaning attached to odd or even numbers anymore — that convention was retired years ago. The major number only increments when the minor count would otherwise get unwieldy; it is a cosmetic reset, not a signal of a huge architectural jump, so jumping from a “5.x” board support package straight to a “6.x” mainline kernel is usually far less scary than the number suggests.

During active development a release candidate carries a -rcN suffix, for example 6.10-rc3. Once a version is tagged without an -rc suffix it is considered released, and any bug-fix-only follow-ups get a third number appended, for example 6.9.1, 6.9.2 — we cover exactly what those stable point releases mean in the next lecture.

The Release Cycle: Merge Window Then Stabilization

Every cycle opens with a two-week merge window, the only period in which genuinely new features are accepted into mainline. Maintainers of the roughly 30 major subsystems — networking, memory management, individual architectures, and so on — send pull requests for code that has already matured in their own trees; almost nothing lands in the merge window that has not already been reviewed for weeks beforehand.

Once the merge window closes, the cycle shifts into stabilization. A sequence of -rc candidates follows, usually seven or eight of them roughly a week apart, and only bug fixes are accepted during this phase — no new features. When the outstanding bug list is short enough, the final version is tagged and the whole cycle repeats.

Getting The Mainline Tree Yourself

You can track development directly from Linus Torvalds’ own tree. The historical git:// protocol is deprecated on kernel.org now, so use the HTTPS mirror instead:

$ git clone --depth 1 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ cd linux
$ git log -1 --oneline

The --depth 1 shallow clone above is worth knowing for a free embedded linux course student on a slow connection — the full history clone can exceed 3 GB, while a shallow clone of just the latest commit is a few hundred megabytes. Pull the newest changes at any time with:

$ git pull

Reading What Actually Changed

A single release cycle can contain well over ten thousand individual commits, so reading the raw log is impractical for keeping up. A far more approachable way to see what changed between two versions on your own machine is to diff the tags directly:

$ git log --oneline v6.8..v6.9 | wc -l
$ git log --oneline v6.8..v6.9 -- drivers/net/ | head

The first command above tells you how many commits landed between two releases; the second narrows that down to just the networking driver subtree, which is a pattern worth reusing whenever you only care about the part of the kernel your board’s peripherals touch.

Real-World Use Case

Say a new sensor you want to use only gained driver support in kernel 6.7, but your SoC vendor’s board support package still ships 6.1. Understanding the version scheme tells you immediately that this is a two-minor-version gap, not a “half a decade behind” situation, and that it is realistic to backport just that one driver rather than attempting a full jump to mainline.

Common Mistakes

• Treating a jump from 5.15 to 6.1 as more disruptive than 5.15 to 5.19, purely because of the major number — the numbering reset in 2011 and again is cosmetic.
• Cloning the full unshallowed mainline history on constrained storage or bandwidth when a shallow clone or a source tarball would do.
• Assuming an -rc kernel is safe for production because it “mostly works” — rc kernels intentionally still contain unresolved bugs.

Best Practices

• For board bring-up work, start from your vendor’s supported branch, not raw mainline, unless you specifically need an unreleased feature.
• Use git log <old>..<new> -- path/ scoped to the subsystem or driver you care about instead of reading the entire changelog.

Summary

Kernel versions follow a predictable two-number scheme with occasional cosmetic major bumps, each release goes through a two-week merge window followed by several weeks of bug-fix-only release candidates, and you can track or diff any of it yourself with a shallow git clone. With this in place, the next lecture covers stable and long-term-support kernels — the versions you will actually deploy on a product.

FAQ

PREV_LEC | NEXT_LEC