Development Model

With the 2.6.x series, the Linux kernel has moved to a relatively

strict, time-based release model. At the 2005 Kernel Developer

Summit in Ottawa, Canada, it was decided that kernel releases

would happen every 2-3 months, with each release being a “major”

release in that it includes new features and internal API changes.

The quick release cycle was chosen as a way to get new features

out to users in a stable form with minimal delay. As a result, new code

– features, device drivers, etc. – is available in a stable kernel within

a few months of its completion, minimizing or eliminating the need for

distributors to backport developmental code into stable releases. So

the kernels released by distributors contain many fewer distributionspecific

modifications, yielding higher stability and fewer differences

between distributions.

Each 2.6.x release is a stable release, in that it is made available

when the list of outstanding bugs is made as small as possible. For

problems which turn up after a kernel release, the “-stable” branch

exists as a way to quickly get fixes out to the community.

The kernel team released the 2.6.19 kernel as a stable release.

Then the developers started working on new features and started

releasing the release candidate versions as development kernels so

that people could help test and debug the changes. After everyone

agreed that the development release was stable enough, it was

released as the 2.6.20 kernel.

While the development of new features was happening, the

2.6.19.1, 2.6.19.2 and other stable kernel versions were released,

containing bug fixes and security updates.This paper focuses exclusively on the main 2.6.x releases, to the

exclusion of the stable updates. Those updates are small, and, in

any case, the design of the development process requires that fixes

accepted for -stable also be accepted into the mainline for the next

major release.