Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linus on Kernel Version Numbering

Posted by CmdrTaco on from the you're-using-slashdot-T_2_5_0_212 dept.

walshy007 writes "In a recent thread it was asked what it would take for an 'unstable' 2.7 development tree to be created, to which Linus replied: 'Nothing. I'm not going back to the old model. The new model is so much better that it's not even worth entertaining as a theory to go back. That said, I _am_ considering changing just the numbering. Not to go back to the old model, but because a constantly increasing minor number leads to big numbers. I'm not all that thrilled with "26" as a number: it's hard to remember. I think the time-based releases (ie the "2 weeks of merge window until -rc1, followed by roughly two months of stabilization") has been so successful that I'd prefer to skip the version numbering model too. We don't do releases based on "features" any more, so why should we do version _numbering_ based on "features"?'"

3 of 416 comments (clear)

  1. Re:A suggestion by Anonymous Coward · · Score: 5, Interesting

    The previous post might sound like a troll, but it makes a great point. Debating over version number schemes feels even more arbitrary and trivial than debating over, say, Code names for projects. Do version numbers or project names really have that much of an influence on how well code is written? If Windows had a kernel numbered 1.33.7 with a beta name of "Loopy Longhorn", would it be a better finished product?

  2. Here's what I think by Godji · · Score: 5, Interesting

    (because surely someone must care)

    If the 2.6 is not going to change, drop it, it's redundant.

    So we're down to 26. I personally find a name like "Linux 28" to be cool. "Linux 41 was released today...". There's nothing wrong with big numbers: see udev.

    The problem with date-based numbering is that when you go from 2008.4 to 2008.10, it looks like you missed a few releases. And if you pre-announce a release, you have to meet your deadline or else rename the release.

    So they could do what Gentoo does - 2007.0, 2007.1, 2008.0, 2008.1, etc. But you still have the problem that every year, you lose count of how many releases have happened. Was there a 2007.2 or did we just go to 2008.0 because we missed the Christmas deadline due to that last-minute security bug?

    They could reduce the problem by using a longer period, such as a decade. (At 6 months for a release, for example, the number will only reach 20, which is not large.) But that's somewhat arbitrary. Plus, being in the 0th decade, we don't want to have 2.6.30 be called 0.3.

    To reduce the complexity on all that, just drop the dates, and what's left is a single big number. No dots, no multiple numbers, easy. Linux 112 is fine by me.

  3. Re:It also reflects... by gmack · · Score: 5, Interesting

    Talk about rose tinted glasses.. The 2.4 /2.5 split that I remember left me at times with TWO unstable kernel series thanks to 2.5.x not being ready for production yet and maintainers trying to backport drivers and to 2.4.x so it could still handle the latest hardware.

    At the worst of it I recall setting up a state of the art server with a SCSI card that crashed randomly on 2.4.x and wouldn't boot on 2.5.x series kernels. Lucky for me the bug was fixed in 2.5.x a week later.

    The new way is easy.. new features and drivers get added to the latest 2.6.x-rc only and only bug fixes get added to the old kernels. This means that if I want to be sure I'm rock solid I just install the latest patch to the kernel I'm running and I can be sure no one has tried to add new features or drivers that would otherwise destabilize my stuff.

    Why anyone would possibly want to go back to the old way is beyond me.