Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux Kernel Release Numbering Revisited

Posted by Zonk on from the important-minutia dept.

An anonymous reader writes "KernelTrap has a summary of a lengthy discussion on the Linux kernel mailing list, in which Linus Torvalds has suggested using an alternative numbering scheme for kernel development. The current 2.6 kernel has been different than older development trees, as active development has been happening at a rapid rate in the officially "stable" kernel, instead of forking the expected 2.7 "development branch" for this effort. In Linus' latest proposal, he suggests using the same odd and even arrangement where an odd number signifies a development release, and an even number signifies a stable release. The difference being that this will all happen under 2.6 and thus at a much more rapid rate. For example, the upcoming 2.6.12 release would focus on fixing bugs and thus be more stable, while the following 2.6.13 release would include new functionality and thus could be less stable."

3 of 93 comments (clear)

  1. This would be helpful by SunFan · · Score: 3, Interesting


    One thing hurting Linux' credibility is that it is hard to predict volatility in it. If it works out that I would know to avoid odd 2.6.x releases, that would be very helpful.

    People want everything, so obviously it's difficult to balance development against stability. This is one area where Solaris has an edge, where even though it takes longer from something to get into the commercial release, at least someone took a look at it before putting it there. Only now has GNOME made it officially into Solaris 10, but there are few issues with it, which is nice.

    --
    -- Microsoft is the most expensive commodity operating system and office suite vendor in the marketplace.
  2. I have a much better idea. by jd · · Score: 3, Interesting
    Let's have two testing phases. Phase 1, the -dev part of the cycle, would be where you have all of the development, adding of new features, breaking of random drivers, etc. Phase 1 finishes when Andrew Morton passes out from shock because all the usable code from his patches has been integrated in the official kernel.


    Phase 2, the -pre part of the cycle, would be where you have the stabilization and verification. It would be less a soft freeze and more a slushy, but the idea is to make sure everything works. Phase 2 finishes when Linus Torvalds is bodily hauled out of the computer room to play five-dimensional scrabble with his kids.


    What you'd end up with is a release that is reasonably stable, AND YET developers would still get to increase the pace of development. You can have it both ways, provided you keep things in sync.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  3. This is good by Anonymous Coward · · Score: 4, Interesting

    This would be a good idea. I compiled 2.6.11 this morning on my laptop, and the alsa nm256 driver locks up the machine on boot :(. This has been happening on and off for some time. I found patches in the module developer's cvs that helped me fix it in 2.6.10, but apparently these didn't make it into 2.6.11 (or it got broken in some other way).

    2.6 is great and there are lots of great new features and development in the kernel. But it would be good if some dot releases were only bugfix releases because right now I think 2.6 is much less reliable than late 2.4 kernels were. On my laptop this only serves to annoy me, but I run servers at work (and a webserver @ home), and right now I don't feel confident at all running newer 2.6 kernels on a production server.