Forgot your password?
typodupeerror
Operating Systems Software Linux

Linus on Kernel Version Numbering 416

Posted by CmdrTaco
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"?'"
This discussion has been archived. No new comments can be posted.

Linus on Kernel Version Numbering

Comments Filter:
  • by thrillseeker (518224) on Wednesday July 16, 2008 @09:19AM (#24212133)
    version 2.0 ...
  • Linus... (Score:5, Funny)

    by Gewalt (1200451) on Wednesday July 16, 2008 @09:20AM (#24212155)
    Linus... has... jumped the shark. The number versions... his version control insanities... He's no longer Linux's greatest advantage. He's now doing more to hold back the community than anything else. (dear god this is going to hurt the karma)
    • Re: (Score:2, Insightful)

      by LWATCDR (28044)

      Please...
      These are such minor things that they are not even a blip on the Radar. I am not a true believer in the Church of Linus or the Church of RMS but this isn't a major problem for Linux.
      I still say that Linux needs a stable binary interface for drivers. I have found no good technical reason not and I find flaws in the political reasons. I don't get to make that call however unless I want to fork the kernel and I know my limits.
      I also think some drivers "Printers, serial ports, web cams..." need to be m

      • Re:Linus... (Score:5, Insightful)

        by setagllib (753300) on Wednesday July 16, 2008 @09:34AM (#24212417)

        http://lxr.linux.no/linux/Documentation/stable_api_nonsense.txt [linux.no]

        Summary: Being able to improve the API regularly keeps Linux largely free of legacy cruft that slows down the development and runtime performance of other systems like Windows. That's why Linux maxes out hardware that runs like a dog under Windows.

        • Re:Linus... (Score:5, Insightful)

          by ivan256 (17499) on Wednesday July 16, 2008 @10:06AM (#24213071)

          The name of that file cleverly describes its contents, even though it is attempting to describe the argument it 'debunks'.

          You can have the best of both worlds (a stable API, and the ability to make changes). The fact of the matter is that the APIs don't change all that often, and frequently they change in a way that would allow for a trivial compatibility layer. Te fact of the matter is that it would *benefit* linux to force the developers of the various driver layers to have to consider interface stability when they make their changes. It would benefit the entire community to make it incredibly difficult for distributors *cough*redhat*cough* to change the driver API for a service layer and release the kernel with the same version number.

          Summary: A stable API doesn't mean you're weighed down with cruft, and any argument based on that premise is nonsense. Any intelligent person making that argument is really saying that they think all drivers should be GPL.

          • Re: (Score:3, Insightful)

            Any intelligent person making that argument is really saying that they think all drivers should be GPL.

            Which may well be the reason -- it seems reasonable to me that an intelligent person could indeed believe that, in the long run, making it too easy for vendors to provide binary-only drivers would hurt Linux in particular, and users of computers in general. Especially if one is also of the belief that operating systems will eventually become "commoditized" and there'll be no money to be made from selling them.

            A similar theory is that a "constantly" changing ABI requires (okay, encourages) any hardware vendo

            • Re: (Score:3, Interesting)

              by ivan256 (17499)

              Let me give you an example device, and based on that you may or may not chose to reconsider your position.

              Consider a Fibre Channel HBA with a storage virtualization processor on it. Depending on the driver software, it has the power to be a simple HBA to connect you to a storage array, a RAID card, a CDP processor... If can fully virtualize your storage, perform optimizations based on what arrays it's connected to, or it can provide base functionality. The simple functions of the device are basically the sa

          • Re:Linus... (Score:4, Interesting)

            by Hal_Porter (817932) on Wednesday July 16, 2008 @11:09AM (#24214381)

            Summary: A stable API doesn't mean you're weighed down with cruft, and any argument based on that premise is nonsense. Any intelligent person making that argument is really saying that they think all drivers should be GPL.

            Exactly.

            It was written by Greg Kroah Hartman who famously broke the Philips webcam driver, causing the maintainer to quit.

            http://www.smcc.demon.nl/webcam/ [demon.nl]

          • Re:Linus... (Score:5, Insightful)

            by Nevyn (5505) on Wednesday July 16, 2008 @11:59AM (#24215263) Homepage Journal

            You can have the best of both worlds (a stable API, and the ability to make changes). The fact of the matter is that the APIs don't change all that often, and frequently they change in a way that would allow for a trivial compatibility layer.

            Your argument is basically that writing shared libraries is just as easy as writing applications, and that maintaining API/ABI compatibility in shared libraries is "easy". Both of which contradict years of experience.

            And, specifically from the kernel perspective, the usual example is the Solaris kernel in the 2.3/2.4/2.5 timeframe (memory is getting old) where they refused to fix a security bug because it would break ABI compatibility. So the corollary to your argument then is that Solaris kernel engineers are idiots?

            • Re:Linus... (Score:4, Interesting)

              by ivan256 (17499) on Wednesday July 16, 2008 @12:39PM (#24215889)

              Show me where I said it's easy. I said that changes are frequently trivial....

              Stability doesn't mean the interface never changes. Stability means that interface doesn't change on a whim... That small changes should be rolled up to minimize the frequency of changes. That compatibility changes should be announced well in advance. That two kernels with the same name and version number from multiple distributors provide the same interface... It means that backwards compatibility should be a goal, but not that you can't break it.

              "Stable" doesn't mean "supported forever". It means "changes as little as possible".

              I'm not sure how you derived the "Solaris kernel engineers are idiots" argument from what I said. Whomever (and I'm sure it wasn't an engineer) decided that maintaining compatibility was more important than fixing a security hole, is an idiot. If breaking compatibility is what you need to do to fix a serious issue, then you break compatibility. If you think I was saying meant that Solaris engineers should have been able to fix the security issue and still maintain compatibility, you need to go back and read what I said again.

            • Re: (Score:3, Insightful)

              by drsmithy (35869)

              Your argument is basically that writing shared libraries is just as easy as writing applications, and that maintaining API/ABI compatibility in shared libraries is "easy". Both of which contradict years of experience.

              Actually I think the point is that when a product is well engineered, a stable API and ABI are quite feasible.

              Supporting evidence for this is that basically every other platform _except_ Linux manages to keep a stable API and ABI.

              The reason for this is, IMHO, large parts of Linux tend to b

              • Re: (Score:3, Insightful)

                by Big Jojo (50231)

                The reason for this is, IMHO, large parts of Linux tend to be "trial and errored" into existence, rather than "specified, designed and implemented".

                Try instead: you *see* more of the trial-and-error on Linux. All operating systems rely on that to various degrees; their problems can't be specified in enough detail to allow a pure "waterfall" design/implementation process. The hardware keeps evolving, as do its applications; nothing stays still. In fact, that waterfall model has been widely discredited

    • Re: (Score:3, Funny)

      by sfraggle (212671)

      You're ... correct ... Linus ... must be stopped ... Mr Spock ... lock phasers on kernel.org ... NOW MISTER!

    • No, what is hurting Linux is that numbering is way to geeky. The next version shouldn't be 2.6.X. For more widespread adoption, we might try cutesy names like Fluffy Rabbit to attract more females and kids. Or for professional sounding names like Tranquil. Of even more generic like Balls. That would be hilarious in everyday conversation. "Today I installed a new set of Balls at work." Hey why is everyone leaving? Hello, is anyone out there?
      • No, what is hurting Linux is that numbering is way to geeky. The next version shouldn't be 2.6.X. For more widespread adoption, we might try cutesy names like Fluffy Rabbit to attract more females and kids. Or for professional sounding names like Tranquil. Of even more generic like Balls. That would be hilarious in everyday conversation. "Today I installed a new set of Balls at work." Hey why is everyone leaving? Hello, is anyone out there?

        Man, you totally forgot the logo. That damned penguin is way too

    • Re:Linus... (Score:4, Interesting)

      by Daniel Phillips (238627) on Wednesday July 16, 2008 @09:40AM (#24212533)

      Linus... has... jumped the shark. The number versions... his version control insanities... He's no longer Linux's greatest advantage. He's now doing more to hold back the community than anything else. (dear god this is going to hurt the karma)

      Rename article title as "Linus on Crack". You are right, Linus is now only Linux's second greatest advantage, Andrew Morton is the greatest. Linus has always been erratic but great. Lately, he really stepped in it a lot, but he is still maybe the best bug hunter that ever lived. Mind you, he tends to have a large hand in creating the horrible complexities that lead to the need for the bug hunt in the first place, but then if he did not we would never have the pleasure of watching him exercise his art.

            http://lwn.net/Articles/215868/ [lwn.net]

      And yes, I agree, Linus is on crack about the version numbers. Just drop the 2. at the beginning and it will all be fixed.

    • by cHiphead (17854)

      For the last damn time, its the tiem of teh internets kids, no more will we jump the shark, forever more shall we nuke the fridge.

  • by Anonymous Coward on Wednesday July 16, 2008 @09:24AM (#24212215)

    What did it ever do to you?

    Besides, it's accomplished a lot:

    In mathematics

    Inherent mathematical properties

    Twenty-six is a composite number [slashdot.org], its proper divisors [slashdot.org] being 1 [slashdot.org], 2 [slashdot.org], and 13 [slashdot.org]. 26 is the only number between a square number [slashdot.org] and a cube number [slashdot.org], the numbers being 25 (5 [slashdot.org] squared) and 27 (3 [slashdot.org] cubed). This was first proved by Pierre de Fermat [slashdot.org].

    It is the 7th distinct biprime [slashdot.org] (2.13) and the 5th with 2 as its lowest non-unitary prime factor. The aliquot sum [slashdot.org] of 26 is 16 with an aliquot sequence of 8 members; (26,16,15,9,4,3,1,0), leading to 0 through the prime 3 the 6th composite number so to do and so the sixth member of the 3-aliquot tree.

    There is no solution to the equation Ï [slashdot.org](x) = 26, making 26 a nontotient [slashdot.org]. Nor is there a solution to x - Ï(x) = 26, making 26 a noncototient [slashdot.org].

    In the classification of finite simple groups [slashdot.org] there are 26 sporadic groups.

    Properties of its positional representation in certain radixes

    Twenty-six is a repdigit [slashdot.org] in base [slashdot.org] three [slashdot.org] (222) and in base twelve [slashdot.org] (22).

    In base ten [slashdot.org], 26 is the smallest number that is not a palindrome [slashdot.org] to have a square [slashdot.org] which is (26^2=676 [slashdot.org]).

    Twenty-six is the number of five-digit prime quadruplets [slashdot.org], the first of which is {13001, 13003, 13007, 13009}[1] [slashdot.org].

    In science

    Astronomy

    • The Saros [slashdot.org] number [nasa.gov] of the solar eclipse [slashdot.org] series which began on -2022 [slashdot.org] March 29 [slashdot.org] and ended on -724 [slashdot.org] May 17 [slashdot.org]. The duration of Saros series 26 was 1298.1 years, and it contained 73 solar eclipses.
  • Excellent notion (Score:5, Insightful)

    by MaulerOfEmotards (1284566) on Wednesday July 16, 2008 @09:25AM (#24212221)
    Linus' idea to switch to date-based version numbering seems excellent to me. From a psychological perspective, humans have difficulties with numbers, especially larger numbers. Also, a purely incremental numbering system without any external relationships (let's call it "semantic anchors" or something) are just that: numbers. By using dates we tie in with an already establish cognitive category which not only tells us the version but also how old it is. Since we Linux folks are usually very conscious about keeping up-to-date (at least the /. crowd) it would be a good and automatic reminder of the state of our system. That is, we use the "date obsolescence effect" (the reason Microsoft stopped naming their software after the year released) to the advantage for security rather than the disadvantage of negative sales.
    • Re:Excellent notion (Score:5, Informative)

      by TheGreek (2403) on Wednesday July 16, 2008 @09:30AM (#24212333)

      (the reason Microsoft stopped naming their software after the year released)

      An [microsoft.com] excellent [microsoft.com] point [microsoft.com], sir [microsoft.com].

    • by KlaymenDK (713149) on Wednesday July 16, 2008 @09:31AM (#24212337) Journal

      Anyone who has problems with "large numbers such as 26" probably shouldn't be doing kernel coding ... just sayin' ;-)

      • by Gewalt (1200451)
        The problem with the "large number" is that 2.6.26 is extremely bad for market perceptions. It's about image with the end users, not the ability's of the programmers. That said, Linus does not care at all about perception with end users. (and never has and never will)
        • Re: (Score:3, Funny)

          by h4rm0ny (722443)

          Oh please! Nobody in a position to be making decisions based on kernel version should be put off by a number like 2.6.26. Can you honestly see a PHB in ever being allowed by the developers to be in a position to say, "No, I don't think we should go with this kernel, lets go with another one." The closest anyone who would be bothered by "2.6.26" gets to making this decision is saying "We will use that one called Hairy Hardon - I like the sound of that one." Kernel versions are off the radar as far as market
          • by Gewalt (1200451)
            That is precisely the type of logic and reasoning that prevents end users from thinking linux is something they might be interested in.
          • Re: (Score:3, Informative)

            by drsmithy (35869)

            Oh please! Nobody in a position to be making decisions based on kernel version should be put off by a number like 2.6.26. Can you honestly see a PHB in ever being allowed by the developers to be in a position to say, "No, I don't think we should go with this kernel, lets go with another one."

            I've already seen those sorts of decisions made on multiple occasions. In fact, I'd be surprised if it *hadn't* happened at anything except the smallest businesses.

            Never underestimate the decisions that will be mad

        • But, numbers are so _disposable_! I want to see a Linux v1,000,000 one day, which would only be like Linux 4.20.436-r2 in the current numbering scheme. Think of all the unused numbers out there in the interim!
        • by TheLink (130905)
          I don't see how kernel versions are relevant to market perceptions.

          AFAIK the end users who know or can figure out what kernel version they are using can handle "large numbers".

          The rest? You'd be lucky if they know whether they are using opensuse or Ubuntu or windows :). Kernel version? What's that? You'd be lucky if they can tell you what version of ubuntu/suse/windows they have without you telling them step by step. Bonus points if they can tell you what build version of windows they are using ;).

          Nobody in
          • by Gewalt (1200451)
            Everyone in the sane world runs kernel 5.1, build 2600 of course! But you do have an excellent point there. Since windows only has one distribution, I often associate the distribution number as the "version" but with linux there are so many distributions, that the kernel number becomes more significant in establishing a common... something. (train of thought has been derailed at the station)
      • by niceone (992278) *
        To be fair, it's probably the whole decimal system he has a problem with, I bet 11010 would be OK.
    • by Hatta (162192)

      What's the problem with big numbers? It conveys the fact that this particular kernel is mature. Also, incrementing the number from 26 to 27 seems like a smaller change relative to changing version 1 to version 2. I really don't see the problem with arbitrary large numbers, after all kernel releases are arbitrary too.

    • by Tim C (15259) on Wednesday July 16, 2008 @09:34AM (#24212421)

      which not only tells us the version but also how old it is

      Who cares how old it is? If it works and isn't known to have any stability or security issues (or at least not ones that affect your use of it), does it matter?

      Software that is newer is not inherently more secure, software that is older is not inherently less secure. I really fail to see how this "date obsolescence effect" helps improve security - I know version 20080213 is older than 20080601, but then I also know that 2.2.12 is older than 2.2.25. Neither of these schemes in themselves say anything at all about the security of the software in question.

      • by FudRucker (866063)
        i agree, with both of you, its plain to see 2.6.26 is newer than 2.6.21 same with the date system, just be greatful Linus is not doing what ubuntu does, how would you like to see:
        B $uname -a
        Linux darkstar Hungry_Hungry_Hippo #1 SMP PREEMPT Mon Jul 14 16:08:23 CDT 2008 i686 Intel(R) Pentium(R) Dual CPU E2200 @ 2.20GHz GenuineIntel GNU/Linux
        • Re: (Score:3, Informative)

          by Tacvek (948259)

          Well actually, 2.6.26 is "Rotary Wombat", and 2.6.25 was "Funky Weasel is Jiggy wit it". Not quite Ubuntu's codenames, and nowhere near as publicized, but equally strange.

    • by clickety6 (141178)

      humans have difficulties with numbers, especially larger numbers.

      Yeah, lucky my phone number is just one digit long. I'd be in real trouble if it was like 7 or 8 digits or longer...

    • by Tom (822) on Wednesday July 16, 2008 @09:42AM (#24212565) Homepage Journal

      date-based is good for continuous processes, which the development isn't and shouldn't be. From the user perspective, my primary concerns are comparisons - is this driver for my kernel version? Do I run the latest kernel version? Is this function available in my current version?

      Numbers are easier to compare than dates. They are also international, while dates aren't. 07.01. means 1st of July in some countries and January 7th in others.

      Major and minor numbers have their place, too. They tell me something about the amount of change. I'll update from 2.6.25 to 2.6.26 without a second thought, as I expect nothing important to have changed. I'll spend a few minutes on the Changelog when I go from 2.6 to 2.7 because I expect a couple of minor things to have changed. I know that going from 2 to 3 will be a major update and might result in all kinds of incompatabilities, so I'd better make sure all my apps are ready first.

      That's why I hate MS year-based versioning system. "Word '97" tells me absolutely nothing about how it compares to '95, '96 or '98. A version number would at least tell me what the manufacturer thinks it's "worth" (even though with MS that was mostly a lie as well).

      And if Linus thinks that "big" (26, yeah right) numbers are a problem for people, then dates will be as well. Quick, how many releases were between 2.6.20 and 2.6.24? Good. Now quick, how many days were between January 17 and March 11? And... how many releases?

      • Re:Excellent notion (Score:5, Informative)

        by bfields (66644) on Wednesday July 16, 2008 @10:58AM (#24214139) Homepage

        Major and minor numbers have their place, too. They tell me something about the amount of change. I'll update from 2.6.25 to 2.6.26 without a second thought, as I expect nothing important to have changed. I'll spend a few minutes on the Changelog when I go from 2.6 to 2.7 because I expect a couple of minor things to have changed. I know that going from 2 to 3 will be a major update and might result in all kinds of incompatabilities, so I'd better make sure all my apps are ready first.

        Kernel development no longer works that way--the current model is, every 2-3 months a new kernel is released, then there's a couple weeks to merge new work, then the rest of the time until the next release is spent tracking down regressions.

        There's never going to be another long-lived development branch: having years where all the real development went on in a kernel that nobody actually used caused all sorts of problems: bugs would pile up because the development branch wasn't getting enough testing, and distro's had to backport a lot just to be able to distribute "stable" kernels with the features and hardware support their customers needed.

        So the kernel version is *always* going to start with "2.6.". Hence the thought that maybe the version numbering doesn't explain the new process as well as something like "2008.07" might.

        And as for incompatibilities, they shouldn't happen. You should be able to drop a new kernel into an old system and everything should work--if not, report it as a bug. There's a few exceptions where some interface is dropped or change, but normally the assumption is that it's something that won't cause a problem for people--so if it does, speak up, they need to hear from you.

        (Of course, the above only applies to real userland interfaces, not to internal kernel interfaces. If you're trying to run a bunch of proprietary out-of-tree code (like the proprietary nVidia driver) inside the kernel, then you're on your own.)

    • I really like the fact the Ubuntu versions have a year.month naming. It much easier for me to remember 8.04 than it is to remember things like Breezy Badger, or Hoary Hedgehog, or even "redhat EL 4.1". I can easily remember that the release was last spring.

  • Open Source (Score:3, Insightful)

    by LordHatrus (763508) <slashdotNO@SPAMclockfort.com> on Wednesday July 16, 2008 @09:25AM (#24212227) Homepage
    The beauty of open source is that if you miss the odd-kernel numbering system more, you can fork the kernel and make your own! Yay! Enjoy maintaining both a stable and experimental code tree, constantly backporting important security fixes and features everyone wants, when you could just be modifying only one tree. Hope you have lots of free time!
  • by wild_quinine (998562) on Wednesday July 16, 2008 @09:28AM (#24212277) Homepage
    This doesn't seem like breaking news to me. It's not even like he's talking about ceasing to use a naming scheme. The scheme is no longer used, now there's just a name. And the name is just a number, which no longer has any (other than historical) relevance. That's all we're talking about, in fact: Getting rid of a vestigial number.
    • by Gewalt (1200451)
      A rose by any other name might smell as sweet, but if you call it shit, will they try to smell it?
  • by Speare (84249) on Wednesday July 16, 2008 @09:29AM (#24212297) Homepage Journal

    Er, you don't do a release for specific "features," but once the release has been made, customers rely on knowing what "features" are (or are not) in the release they're using. There should be a sane and rational comparison rule to know if one version is newer (and likely to have more good "features" and fewer bad "features") or not. Ubuntu uses dorky names but anyone who knows the alphabet and the comparison rule can at least decide if "Beaver" is older or newer than "Walrus." I don't care what the kernel uses, but it should be something people can figure out the ordering.

    Hey, I heard the Parameterized Ultra-Fair Order One Irreversible Hypoxic Process Scheduler is in the newest kernel. Wait, is that in 2.6.43.-12b34_+omicron-rc6, or not?

    • by setagllib (753300)

      Ubuntu releases are numbered by their date too, including very specifically the year and month. Point releases like 8.04.1 don't refer to days or weeks though, but increments on top of the year.month system.

      The nicknames are just for non-geeks. I think they really messed up with Intrepid Ibex, the first time I've preferred to call it $noun instead of $adjective, usually saying Gutsy or Hardy or whatever.

    • by IBBoard (1128019)

      Shame the early Ubuntu's [wikipedia.org] began with W and B and completely messed up that scheme ;)

      As for whether it is in 2.6.43.-12b34_+omicron-rc6, that depends how much an omicron is and what effect it has on adding it the the 12th build of the 34th beta of 2.6.43, which is now in RC6 status.

      Besides, I heard the Parameterized Ultra-Fair Order One Irreversible Hypoxic Process Scheduler is in the newest kernel. Wait, is that in 2.6.26.10, or not? Version numbers still tell you nothing about what's in it. However you name

    • Re: (Score:3, Informative)

      by drew (2081)

      Unfortunately, the alphabetical naming scheme for Ubuntu "only" goes back about two years. Before that, they were more random. For example, which came first, Hardy Heron, or Hoary Hedgehog?

      I was wondering how long it would be before somebody mentioned Ubuntu, though, because Ubuntu already uses a date based version number scheme. The current version is 8.04 LTS, released in April, 2008. The other versions released in the last two years are 7.10, 7.04, 6.10, and 6.06 LTS. The date based version has anot

  • Dang! (Score:2, Funny)

    by certain death (947081)
    _I_ _Really_ _hate_ reading Linus' _email_ with all _his_ _underlining_ for emphasis!!!_-_-_-_ _REALLY_!
  • Here's what I think (Score:5, Interesting)

    by Godji (957148) on Wednesday July 16, 2008 @10:01AM (#24212959) Homepage
    (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 [kernel.org].

    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 [gentoo.org] 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.
  • by pr0nbot (313417) on Wednesday July 16, 2008 @10:06AM (#24213097)

    Can anyone help? I installed the 2.6.26 kernel on my pentium, but it keeps saying I have version 2.6.25999999999993 installed?

  • Labeling a release based on the date is not as useful as some people think. Sure, it lets you know which releases are newer/older, and it gives you a reasonable idea of which ones might be the most up-to-date, but it has some major drawbacks.

    One of the problems is, if people can't remember a number like 26, I'm not sure how they are going to remember a number like 2008-07-16. Also, it forces people who want to know about kernels to become a history expert. Does anyone actually know off the top of their h

  • by dwheeler (321049) on Wednesday July 16, 2008 @10:57AM (#24214133) Homepage Journal

    I propose Offset 2000 version numbers, i.e., "(y-2000).mm[.dd]". The first number is the year minus 2000, followed by "." and a two-digit month, optionally followed by "." and a two-digit day when there's more than one release in a month. So version 8.07 would be the first release in July 2008. If you made a later release on July 17, it'd be 8.07.17 (so if a project makes many releases in a month, you can again determine how old yours is).

    Date-based version numbers have a lot going for them, because at a glance you know when it was released (and thus you can determine how old something is). If you choose the ISO order YYYY.MM.DD, the numbers sort very nicely; Debian packages often use YYYYMMDD for versioning [debian.org]. But there's a problem: full year numbers, or full dates in this format, are annoyingly large. For example, version numbers 2008.07.16 and 20080716 are painfully long version numbers to remember. That's not necessary.

    So, use dates, but shorten then. Since nothing today can be released before 2000, shorten it by subtracting 2000. Note this is subtracting - there's no Y2K-like rollover problem, because the year 2100 becomes 100 and the year 3000 becomes 1000. The second number is the month; using a two-digit month means you don't have the ambiguity of determining if "2.2" is earlier or later than "2.10" (you would use "2.02" instead). If you need to disambiguate day releases (or you make additional releases in the same month), add "." and a two-digit day.

    These version numbers are short, they're easy to compare, and they give you a clue about when it happened. Ubuntu already uses this scheme for the first two parts [ubuntu.com], so this scheme is already in use and familiar to many.

    If you use a time-based release system, using this version numbering system is easy, and you can even talk about future releases the same way. But what if you release software based on when the features are ready, or want to talk about the system under development? You can't easily call it by the version number, since you don't know it yet, but that's not really a problem. In many cases, you can just talk about the "development" version or give a special name to the development version (e.g., "Rawhide" for Fedora). If you need to distinguish between multiple development versions, just give each of them a name (e.g., "Hardy Heron" for Ubuntu); on release you can announce the version number of a named branch (e.g., "Hardy Heron is 8.04"). This is more-or-less what many people do now, but if a lot of us used the same system, version numbers would have more meaning than they do now.

  • by Cro Magnon (467622) on Wednesday July 16, 2008 @11:17AM (#24214543) Homepage Journal

    If I see a version number of 2.00, I can ASSume that there are significant changes from 1.X. Also, as an "ohoh" version, it's more likely to have bugs than 2.1.

    A year-based version tells me when it was released, but not much else. Maybe there was a major change in August, and V2008.08.01 is an "ohoh" version.

    Named versions tell me even less. I might ASSume that "Perfect Penguin" is later than "Ornery Onyx", but I don't know how much has changed, or how long it took to release.

  • by aegl (1041528) on Wednesday July 16, 2008 @02:17PM (#24217749)

    Several slashdot readers have made comments like "I can easily upgrade from 2.6.n to 2.6.n+1 because not much will have changed".

    This is all part of the delusion of version numbers. The changes between releases are only limited by how many can be squeezed into the merge window. With an increasing number of developers, and development tools that seem to be scaling the overall trend seems to be that the n+1 release is progressively more different that its predecessor. Here are the diffstats for the last few kernels:

    2.6.15 -> 2.6.16 6721 files changed, 392461 insertions(+), 202469 deletions(-)
    2.6.16 -> 2.6.17 6321 files changed, 416664 insertions(+), 308709 deletions(-)
    2.6.17 -> 2.6.18 8972 files changed, 381890 insertions(+), 217058 deletions(-)
    2.6.18 -> 2.6.19 8040 files changed, 515161 insertions(+), 291784 deletions(-)
    2.6.19 -> 2.6.20 5825 files changed, 262475 insertions(+), 136162 deletions(-)
    2.6.20 -> 2.6.21 6568 files changed, 319232 insertions(+), 175247 deletions(-)
    2.6.21 -> 2.6.22 7620 files changed, 519591 insertions(+), 266699 deletions(-)
    2.6.22 -> 2.6.23 7203 files changed, 406268 insertions(+), 339071 deletions(-)
    2.6.23 -> 2.6.24 10209 files changed, 776107 insertions(+), 483031 deletions(-)
    2.6.24 -> 2.6.25 9738 files changed, 777371 insertions(+), 404514 deletions(-)
    2.6.25 -> 2.6.26 8676 files changed, 595389 insertions(+), 416139 deletions(-)

  • by Todd Knarr (15451) on Wednesday July 16, 2008 @02:56PM (#24218445) Homepage

    Date-based versions don't help me very much. What I need/want from a version number is a clue as to how big the changes are. Is this version just bug-fixes and I shouldn't see much impact beyond fixing those errors? Is this a version that's got some significant enhancements and changes but my existing configuration should convert over without too much trouble and, while I'm going to see some impact, it shouldn't break my workflow and documents/code too badly? Or is this a big change with a whole new way of looking at large parts of the system, where I can expect major things to be a lot different and to have to adapt most everything to the new way the world is? The standard 3-part version numbers give me that kind of hint (at least when the developers stick to that accepted interpretation of the parts).

God doesn't play dice. -- Albert Einstein

Working...