The myriad versions of the Linux kernel released every now and then, can be quite confusing for a newbie to look at, for the first time. In this post, I would try to give an abstract of how the various kernels are numbered, and a rough idea of how the Linux development cycle goes on.
The Old Order:
Prior to the 2.6 kernel release, there were two types of kernels - Development kernels and the stable kernels. These were differentiated by their minor release numbers being odd or even (odd for development kernels, even for stable ones). So, for example, the kernel 2.4 was a stable kernel ('2' being the major release number, '4' being the minor release), while 2.5 was a development kernel. A Development kernel often used to be a chaotic mess, with the code undergoing massive changes to introduce new features, completely overhauling code paths etc. Once the development kernel started showing resemblance of some stabilisation, Linus would fork out a stable kernel release - so the 2.5 kernel series would stabilize into the 2.6 series. However, this type of versioning (odd minor release representing a development kernel) has been discontinued since 2004, and the 2.6 kernel series marks a breakaway from such semantics of versioning.
The New Order:
Starting with the 2.6 kernel series, the notion of having different development and stable kernel trees has been dropped. To quote Greg K-H (a leading Linux developer) - "Every release is a preferred release". The kernel development now ensues in the form of 'rc' releases (rc for release cycle) or 'revisions'. So, for a stable release say, 2.6.17 ('17' is the revision), a new branch 2.6.18-rc1 is forked out to accept new features etc., initially for approximately two weeks. The subsystem maintainers send multitudes of patches to be merged into the -rc1 branch. If someone misses out on the rc-1 branch, then he/she can send the patches for merging into the rc-2 branch. Thereafter, mostly it is the bug-fixes or regressions introduced in the -rc1 and -rc2 branches that are tracked and fixed in the subsequent rc releases. Once a -rc(n) branch stabilizes, the next kernel revision, in this case, 2.6.18 is released. A typical release cycle (say, from 2.6.17 to 2.6.18) typically takes around 2-3 months.
An additional thing here is that, since every kernel is a 'preferred' release, a stable kernel branch is also maintained by Greg K-H and Chris Wright. Typically, its the bug-fixes and security updates already present in an upstream tree, ie. one of the -rc releases, that go into the stable tree. So, if 2.6.18-rc1 includes an important bug-fix, it may be back-ported to 2.6.17 and the new 'stable' kernel released as 2.6.17.1. If there are more bug-fixes in say, 2.6.18-rc2 or 2.6.18-rc3 then they may be again back-ported to 2.6.17.1 and a new kernel released as 2.6.17.2. However, no new features are accepted when releasing a 'stable version' of a revision. Its almost always the fixes and the security updates. Following diagram sums it all up.
Another point worth noting here is that, the stable-branch (of Greg K-H and Chris Wright) isn't maintained forever, for a particular kernel revision. So, for example, once the 2.6.18 kernel is out, and we already have a stable kernel 2.6.17.4 (as in the figure), then perhaps there would be at most one more stable kernel release like 2.6.17.5, to back-port fixes from the 2.6.18 kernel (or not even that). However, beyond that, the stable revision (2.6.17.4/5) is dropped and the next stable release would be a 2.6.18.1 and so on. That said, exceptions do exist. For example, in case of Long Term Support (LTS, ex: 2.6.32 release), kernel vendors like Suse and RedHat might want to continue back-porting fixes from upstream branches even though a newer kernel release is there, to maintain support commitments of the LTS release (Greg K-H was till recently an employee of SUSE, and Chris Wright is an employee of RedHat, so this is entirely possible).
This model of development has been in place for quite some time now, with the minor renaming of the 2.6.40 release to a 3.0.0 release. Once, the 2.6.39-rc7 was out, instead of stabilizing it into a 2.6.40 release, Linus Torvalds renamed it into 3.0.0 release in order to do away with a rather inconvenient numbering system in honour of 20th anniversary of Linux (sic). See the original post on LKML here.
So, the only thing that has changed is that a stable release is marked as 3.x.y.z rather than 2.6.x.y. As mentioned in the link above, there have been _no_ major changes in moving from 2.6 to 3.0 series.
As of this writing, the latest stable release is 3.4.4 (based on 3.4 kernel) while the latest development release is 3.5-rc7). So, perhaps a stable kernel 3.4.5 can be expected soon, back-porting from 3.5-rc7 and subsequent releases.
Postscript:
It should be clear by now that the mainline tree maintained by Linus (linux/kernel/git/torvalds/linux-2.6.git) won't contain any stable-branch releases ie. it won't have a 2.6.32.1 release, it would have just the 2.6.32 release. The 2.6.32.1 release can be obtained from Greg's and Chris' tree (linux/kernel/git/stable/linux-stable.git). Similarly, if you are looking for the 3.4.4 stable release, look at the stable tree. The 3.4 release however, can be found in either of the trees.
References:
1. Greg K-H on Linux (http://www.youtube.com/watch?v=L2SED6sewRw)
2. http://www.kroah.com/lkn/
3. Linux Kernel Development - Robert Love
The Old Order:
Prior to the 2.6 kernel release, there were two types of kernels - Development kernels and the stable kernels. These were differentiated by their minor release numbers being odd or even (odd for development kernels, even for stable ones). So, for example, the kernel 2.4 was a stable kernel ('2' being the major release number, '4' being the minor release), while 2.5 was a development kernel. A Development kernel often used to be a chaotic mess, with the code undergoing massive changes to introduce new features, completely overhauling code paths etc. Once the development kernel started showing resemblance of some stabilisation, Linus would fork out a stable kernel release - so the 2.5 kernel series would stabilize into the 2.6 series. However, this type of versioning (odd minor release representing a development kernel) has been discontinued since 2004, and the 2.6 kernel series marks a breakaway from such semantics of versioning.
The New Order:
Starting with the 2.6 kernel series, the notion of having different development and stable kernel trees has been dropped. To quote Greg K-H (a leading Linux developer) - "Every release is a preferred release". The kernel development now ensues in the form of 'rc' releases (rc for release cycle) or 'revisions'. So, for a stable release say, 2.6.17 ('17' is the revision), a new branch 2.6.18-rc1 is forked out to accept new features etc., initially for approximately two weeks. The subsystem maintainers send multitudes of patches to be merged into the -rc1 branch. If someone misses out on the rc-1 branch, then he/she can send the patches for merging into the rc-2 branch. Thereafter, mostly it is the bug-fixes or regressions introduced in the -rc1 and -rc2 branches that are tracked and fixed in the subsequent rc releases. Once a -rc(n) branch stabilizes, the next kernel revision, in this case, 2.6.18 is released. A typical release cycle (say, from 2.6.17 to 2.6.18) typically takes around 2-3 months.
An additional thing here is that, since every kernel is a 'preferred' release, a stable kernel branch is also maintained by Greg K-H and Chris Wright. Typically, its the bug-fixes and security updates already present in an upstream tree, ie. one of the -rc releases, that go into the stable tree. So, if 2.6.18-rc1 includes an important bug-fix, it may be back-ported to 2.6.17 and the new 'stable' kernel released as 2.6.17.1. If there are more bug-fixes in say, 2.6.18-rc2 or 2.6.18-rc3 then they may be again back-ported to 2.6.17.1 and a new kernel released as 2.6.17.2. However, no new features are accepted when releasing a 'stable version' of a revision. Its almost always the fixes and the security updates. Following diagram sums it all up.
Another point worth noting here is that, the stable-branch (of Greg K-H and Chris Wright) isn't maintained forever, for a particular kernel revision. So, for example, once the 2.6.18 kernel is out, and we already have a stable kernel 2.6.17.4 (as in the figure), then perhaps there would be at most one more stable kernel release like 2.6.17.5, to back-port fixes from the 2.6.18 kernel (or not even that). However, beyond that, the stable revision (2.6.17.4/5) is dropped and the next stable release would be a 2.6.18.1 and so on. That said, exceptions do exist. For example, in case of Long Term Support (LTS, ex: 2.6.32 release), kernel vendors like Suse and RedHat might want to continue back-porting fixes from upstream branches even though a newer kernel release is there, to maintain support commitments of the LTS release (Greg K-H was till recently an employee of SUSE, and Chris Wright is an employee of RedHat, so this is entirely possible).
This model of development has been in place for quite some time now, with the minor renaming of the 2.6.40 release to a 3.0.0 release. Once, the 2.6.39-rc7 was out, instead of stabilizing it into a 2.6.40 release, Linus Torvalds renamed it into 3.0.0 release in order to do away with a rather inconvenient numbering system in honour of 20th anniversary of Linux (sic). See the original post on LKML here.
So, the only thing that has changed is that a stable release is marked as 3.x.y.z rather than 2.6.x.y. As mentioned in the link above, there have been _no_ major changes in moving from 2.6 to 3.0 series.
As of this writing, the latest stable release is 3.4.4 (based on 3.4 kernel) while the latest development release is 3.5-rc7). So, perhaps a stable kernel 3.4.5 can be expected soon, back-porting from 3.5-rc7 and subsequent releases.
Postscript:
It should be clear by now that the mainline tree maintained by Linus (linux/kernel/git/torvalds/linux-2.6.git) won't contain any stable-branch releases ie. it won't have a 2.6.32.1 release, it would have just the 2.6.32 release. The 2.6.32.1 release can be obtained from Greg's and Chris' tree (linux/kernel/git/stable/linux-stable.git). Similarly, if you are looking for the 3.4.4 stable release, look at the stable tree. The 3.4 release however, can be found in either of the trees.
References:
1. Greg K-H on Linux (http://www.youtube.com/watch?v=L2SED6sewRw)
2. http://www.kroah.com/lkn/
3. Linux Kernel Development - Robert Love
Good one. Thank you for simple and detailed explanation :)
ReplyDelete