Sunday, October 10, 2010

Numbering the Linux kernel

As of October 10, 2010, the most stable kernel release is 2.6.35.7.1 Using this number, here's how the numbering scheme works. The 2 stands for the second big update in the kernel's design. The 6 stands for important modifications to 2. 35 stands for smaller modifications; since it incorporates new features and drivers that go into a solid release, the third number in the series defines the most current kernel. (This is different from a version--the 2, in this case--which indicates a major revamping of the kernel's code.) The 7 stands for a set of very small modifications--most of which are on the level of typos and debugging.2

Until 2004, the development of stable and unstable releases was numbered differently. When the kernel version was unstable, the second number was odd; months of development and debugging would then follow until they finished an even-numbered stable release. But this pattern ended in 2004; by then, development and testing weren't falling into an easy "even is stable, odd is unstable" pattern. From then on, the numbering system became what it is today.

However, in 2008, Linus Torvalds suggested changing the numbering scheme to match the date somehow:

"If the version were to be date-based, instead of releasing 2.6.26, maybe we could have 2008.7 instead. Or just increment the major version every decade, the middle version every year, and the minor version every time we make a release. Whatever. I could also see the second number as being the 'year', and 2008 would get 2.8, and then next year I'd make the first release of 2009 be 2.9.1 (and probably avoid the '.0' just because it again has the connotations of a 'big new untested release', which is not true in a date-based numbering scheme). And then 2010 would be 3.0.1 etc.."3

But since the most recent kernel doesn't have a 3.0.x.x number, the numbering system hasn't used either of these formats.

The numbering system today is effective and flexible because it keeps track of the changes as time goes by. Updating the first number every time a minor update is released isn't efficient; having lesser numbers stand for different levels of revision keeps the first number small and the system easier to understand. But as you can tell from all the sources, it took a bit of research to find out what each number means. Another disadvantage I see is that unless it's established what constitutes a major or minor change, the number could be updated unnecessarily (e.g., because a few comments were added). So unless a new system is discovered--one that works better than the system in use today--
the current system works fine, and there's no need to change it.

-----

Works Cited:


1. The Linux Kernel Archives.

2. Linux kernel version numbering.

3. Kernel Release Numbering Redux.

No comments:

Post a Comment