Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×
Operating Systems Linux

Torvalds Polls Desire for Linux's Next Major Version Bump 199

jones_supa writes: Linus Torvalds made this post about Linux version numbering: "So, I made noises some time ago about how I don't want another 2.6.39 where the numbers are big enough that you can't really distinguish them. We're slowly getting up there again, with 3.20 being imminent, and I'm once more close to running out of fingers and toes. I was making noises about just moving to 4.0 some time ago. But let's see what people think. So — continue with v3.20, because bigger numbers are sexy, or just move to v4.0 and reset the numbers to something smaller?" To voice your opinion, the Google+ post allows you to discuss the matter and cast a vote in a poll.
This discussion has been archived. No new comments can be posted.

Torvalds Polls Desire for Linux's Next Major Version Bump

Comments Filter:
  • by tomxor ( 2379126 ) on Friday February 13, 2015 @09:59AM (#49046509)
    Makes it sound like what determines a version bump is somewhat arbitrary, are kernels just too complex for them to fit into a simple versioning convention?
    • by Himmy32 ( 650060 )
      By it's very nature the changes to the kernel will be small and incremental. As to not break everything. So if all of the changes are small it's unlikely that you would ever reach definitive threshold for a major version. This is compared to other project that do major upgrades, feature additions, or complete rewrites.

      Every version system is arbitrary. The entire point is utilitarian and supposed to be helpful in keeping track of which version you are using.
      • If the kernel doesn't fit the usual versions model, why not just go with the freakin' date?

        Linux Kernel 2015-02

    • by jellomizer ( 103300 ) on Friday February 13, 2015 @10:36AM (#49046761)

      Version Numbers in general are outdated for application. The line between a Major and Minor version is huge.
      We have been on Mac OS X (10) for 14 years. with have been getting point updates over the time.
      Microsoft during that time has had 4 Major updates (That is with the insane longevity of XP).
      We have Chrome and Mozilla who for the most part dumped minor versions and we get a Major version every other week.

      In my mind a Major Number should be when there is a large change to the system. Going back and rewriting a lot of code, adding/removing features. While the minor version is just a patch, giving better performance, but the core architecture is nearly identical. Still in my mind, there is a lot of subjective debate.

      • by mlts ( 1038732 )

        You hit the nail on the head. The problem, especially with mature platforms, is that big changes tend to not happen. We are not seeing any new bus architectures, nor are we seeing anything that fundamentally changes the kernel's architecture, so there are two schools of thought:

        The first is to only bump up a major version number only if something radical happened, which the Linux kernel used to do (I remember back in the 1.x days, seeing 1.1.100.) Then there is bumping the major number routinely.

        I'm of t

        • by Dog-Cow ( 21281 )

          I'm going to take "non-technical people" and assume that means people who don't care about the kernel. And then I'll tell you that the version the number of the kernel is irrelevant because non-technical people don't even know what it is. They might know which distribution they're using. Maybe.

      • by flink ( 18449 ) on Friday February 13, 2015 @11:58AM (#49047419)

        Version Numbers in general are outdated for application. The line between a Major and Minor version is huge.
        We have been on Mac OS X (10) for 14 years. with have been getting point updates over the time.
        Microsoft during that time has had 4 Major updates (That is with the insane longevity of XP).

        It depends on what you are talking about. The internal version number for Windows 7 is 6.1.x (Windows 8.1 is v6.3). So if we are going by marketing-driven release numbers, then there have been 6 or so major Windows NT release since 1996 (Windows NT 4.0, Windows 2000, Windows XP, Vista, 7, 8). However, if you go by the engineering version number there have been just 2: Window 2000 was NT v5.0 and Windows Vista was NT v6.0.

      • We have Chrome and Mozilla who for the most part dumped minor versions and we get a Major version every other week.

        And then we have emacs where they dropped the major version number (see cute wikipedia story)..

        In my mind a Major Number should be when there is a large change to the system.

        On topic: Lots of things have changed in the linux 3.x series. For example the kernel now supports docker out of the box (if I recall correctly). This was added and improved over multiple releases, but there is a big difference between 3.0 and now. IMO, it's totally valid to make a major release...

        Anyways, at the end of the day, this doesn't matter. But it is so lovely simple that everybody can have an opinion a

    • I adopted a convention for my software: x.y.z

      "x" changes if there are some major features or change how the software works.
      "y" changes if there are some new features.
      "z" changes if there are only bug fixes.

      Keeps it simple, easy to remember, and users reacted very well to it since they can immediately tell how big of a release it is.

      • by amck ( 34780 )

        Thats the Semantic versioning convention:
        http://semver.org/ [semver.org]

        • No, it's not. Semver mandates that the major version is bumped exactly when there are "incompatible API changes". This is a simplified (and les well-defined) version.
          • I'll be damned, I did not know this was a thing, I just came up with something that was logical, and served to communicate with user the nature of the release.

            And you are right, this is not semver. I don't do backward incompatible changes, so the major number would never change thus the major number as specified in semver is useless for me. Nice to see it is pretty close though.

      • by Lodragandraoidh ( 639696 ) on Friday February 13, 2015 @01:13PM (#49048143) Journal

        I would argue for adding an extra decimal point: W.X.Y.Z

        'W' - Major Release - reserved for significant rewrite/technology/architectural changes

        'X' - New Feature Release - significant changes to existing architecture/technology

        'Y' - Minor Release - minor changes to existing architecture/technology - could be for major bug patches, or other miscellaneous performance enhancements that we want to differentiate from previous releases.

        'Z' - Patches - things that do not rise to the level of a full release - could be for minor bug fixes, or to track iterative evolution and re-factoring of a small component of the overall system. Having the extra number here would allow you to keep each individual decimal number smaller by selectively rolling the number above it without necessarily impacting your major release numbers - basically it splits up the last number - which seems to get a lot of use - into two numbers to spread the load.

        • I would argue for adding an extra decimal point: W.X.Y.Z

          We did at some point, but users were not able to remember the full version number. People already have trouble sometimes remembering 3 numbers. They start telling you things like "I have the latest version", which they often don't, or confusing 10.0.1 with 10.1.0. 4 numbers makes the situation much worse.

          Why is this important? because when someone sends you a bug report, you want to know exactly what version they are using. You may or may not have fixed the bug already, so having accurate version nu

          • We did at some point, but users were not able to remember the full version number. People already have trouble sometimes remembering 3 numbers. They start telling you things like "I have the latest version", which they often don't, or confusing 10.0.1 with 10.1.0. 4 numbers makes the situation much worse.

            Why is this important? because when someone sends you a bug report, you want to know exactly what version they are using. You may or may not have fixed the bug already, so having accurate version numbers matter.

            The fix for the human factors problem is to automate the generation of the bug report on the user's system such that it captures the version information for things critical to your app (e.g. kernel version, libraries versions, your application's version etc...). Have the application itself do this upon failure, and/or provide a tool to capture the requisite information after the fact.

            Then, make it a policy not to accept bug reports without the appropriate error log data accompanying it (with clear instru

    • by Kjella ( 173770 )

      Makes it sound like what determines a version bump is somewhat arbitrary, are kernels just too complex for them to fit into a simple versioning convention?

      More like the other way around, Linux doesn't ever make changes that break userspace so the first version number is pretty much set in stone, it should be 2.60 or so now really. I don't get it though, the only thing he's encouraging is to just code majorVersion >= 2 and if he ever does decide to break a userspace API everything will break. But since he hasn't done so in the last 19 years (2.0 was in 1996) I guess he figured that just won't be necessary, ever.

  • by Anonymous Coward on Friday February 13, 2015 @10:00AM (#49046515)

    Why not just skip directly to Linux 10?

    • by arfonrg ( 81735 ) on Friday February 13, 2015 @10:51AM (#49046853)

      You can't just skip over Linux ME, Linux 2000, Linux Vista, Linux XP and Linux 8!

      • Re: (Score:3, Funny)

        by Anonymous Coward

        Linux NT is the best. We can call it LiNT. Then wait for Mint to make a distribution based on LiNT.

        "Do you run LiNT Mint?"

      • Please, oh please - can we at least skip over Linux Vista?

        Actually, many years ago I tried to run Red Hat 6 (IIRC). I was new to Linux so I knew there would be a learning curve. But after a great deal of misery, I finally discovered that there was something fundamentally broken about the then-current version of GCC, and there was no possible way for a newbie like me to compensate. So, maybe that was the "Vista" moment of "the GNU/Linux system".

        Since then, I've tried several Linux distributions and general

        • by caseih ( 160668 )

          I doubt it will be. Sounds to me that Windows fits you just fine. That being the case, you have little incentive to really try Linux, so I don't think 2015 will be much different for you than any of the previous years. True Linux distros have gotten better and easier--Linux Mint would probably work for you right now out of the box without having to mess with browser plugins or tweaking audio. But you don't seem to have much motivation to try Linux, so much smaller issues are going to be stumbling blocks f

          • Good points. You seem to be confirming what I've long suspected: that things that seem easy on a system you have experience with, but seem hard on a system you don't have experience with, may be more a function of the experience than the system.

            I remember many years ago when I was first learning Windows 95 that I had to go and ask experts a lot of questions on how to do things. Now it all seems so easy - except when Microsoft shuffles the deck chairs for no good reason. For example, I've just been forced

    • Or how about Linux 2015? And if another release comes out mid-year we can go with Linux 2015 R2?

  • by Anonymous Coward
    Richard Stallman can help.
  • Not quite sure (Score:5, Insightful)

    by Psychotria ( 953670 ) on Friday February 13, 2015 @10:06AM (#49046543)

    I'm not really sure because I don't know if Linux adheres to Semantic Versioning [semver.org] or not (previous bumps in the major version number might suggest not). Semantic versioning doesn't work for every project but I am pretty sure that (if Linux used semantic versioning) that the next release would not introduce any incompatible changes to the API/ABI.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      No, the Linux kernel does not have adhere to Semantic Versioning. For one thing, it is backwards-compatible until the last user of an userspace ABI either dies or sleeps on the job long enough (a few months) to not notice it is going away in the latest kernel if someone doesn't speak up. There are exceptions to this, mostly related to how painful it is to keep a feature still working, but they are very rare.

      Note: internally the Linux APIs/ABIs change all the time, and breaking anything and everything tha

    • Related to the above, I'm not even 100% sure if Torvalds' mantra of "WE DO NOT BREAK USERSPACE!" is the best course of action. If userspace needs breaking, then break it and bump the major version number, otherwise things could potentially end up as horrible as MS operating systems and their attempt at preserving that over time.

      • by halivar ( 535827 )

        After 24 year, I think that if it were to become the MS monstrosity, it would have done so by now. Consider how many times the DOS/Windows kernel has been rebooted in that time.

        • by Rich0 ( 548339 )

          After 24 year, I think that if it were to become the MS monstrosity, it would have done so by now. Consider how many times the DOS/Windows kernel has been rebooted in that time.

          I'm not sure MS is really the right comparison here. They're actually fairly famous for never breaking userspace. I wouldn't be surprised if Calc.exe from Windows 386 ran fine on Windows 8. Device drivers are a different matter.

    • by Meneth ( 872868 )
      It did adhere to Semantic Versioning before v3.0. They dropped it because Linus felt the "39" in 2.6.39 was too big.
      • by arth1 ( 260657 )

        Indeed.
        2.0 -> 2.2 -> 2.4 -> 2.6 all heralded major changes, while 2.6 -> 3.x did not.
        I think there should have been one major lift (to 2.8?) in there with devicetree - that's a big change that introduces lots of potential incompatibilities and required changes to userland. But that one went in a minor number, which seems rather wtf to me.

        My recommendation: Switch to 4.1 and go back to an odd/even system so 4.2 will be the next stable.
        Also make a marker for whether a stable kernel is also desig

        • Switch to 4.1 and go back to an odd/even system so 4.2 will be the next stable.

          Linus already decided the odd/even system was a bad idea, and he had good reasons for it. I don't think there's any way he'll go back.

      • It did adhere to Semantic Versioning before v3.0.

        No, it didn't. The numbers did have some meaning before v3.0, but not the semver meanings. Prior to v3, the first digit, the kernel version, was incremented only when there were major changes, as there were from 0 to 1 and 1 to 2. The second digit had special meaning; even values were for "stable" releases and odd values were for "development" releases. This ended when Linus realized that it wasn't getting him the sort of testing he wanted of the development releases, and was also encouraging too-large chan

  • by What'sInAName ( 115383 ) on Friday February 13, 2015 @10:07AM (#49046551) Homepage Journal

    Personally, I think it would be better to use the date as the version "number," though I'm sure that people who have thought about this issue more than I have can come up with reasons that's not a good idea.

    One other idea, why not just use the git commit hash? That would really roll off the tongue and be easy to remember. I can see it now:

    "Just released, Linux Kernel 634713bc047a87bf8eac9674765ae793478c50d2!"

    • by tomxor ( 2379126 )
      If only commit hashes were ordered
    • If you guys decide to go with the date, please go with ISO dates. There's nothing more confusing than stupid American dates [imgur.com].

      • There are no stupid date formats - just stupid people.

        Symbols, and words, phrases, and sentences created with those symbols are neither right or wrong in and of themselves. In a given context (e.g. spoken words, computer file name, database representation, printed document etc) each and every method has its place.

        That being said, I do agree, and use myself ISO date/time formats when dealing with data, file names, and other things that I want to conveniently order by date/time. (yyyymmddhhmmss). That

    • That's how I do my version numbers. Today would be 20150213. Simple and also has the bonus of giving the exact build date.

  • by B5_geek ( 638928 ) on Friday February 13, 2015 @10:12AM (#49046575)

    I don't have a problem with the way it's currently done, but i have a possible solution that _might_ keep everybody happy.

    based-10 numbered like an array.

    You version numbers (minus the first significant digit) all go from 0-9, and once a minor-revision pushes a .9 up, it doesn't goto .10 it then reset back to a 1.0

    i.e. so v4.9.0.10 = v4.9.1

  • by HighOrbit ( 631451 ) on Friday February 13, 2015 @10:19AM (#49046617)
    I thought the point of a major version (not necessarily in the Linux kernel, but software generally), was to signal a major change that either:
    • includes ground-breaking new features
    • includes serious archtectural reworking
    • breaks backwards compatibility

    If the changes are merely incremental bug-fixes and minor feature additions, stay with minor versioning. Otherwise, you are not versioning; you are branding (viz: Windows 8... which IIRC is version 6.2)

    • Re: (Score:2, Redundant)

      by OzPeter ( 195038 )

      I thought the point of a major version (not necessarily in the Linux kernel, but software generally), was to signal a major change

      Look at the choices in the poll itself:

      1. I like big versions, and I cannot lie
      2. v4.0 'cause I get confused easily

      The poll is such a joke that for a moment I thought it was meant for April fools day.

    • Lots and lots of minor fixes and changes add up to serious architectural rework. Ground-breaking new features are added when ready - one by one - every few months it seems I read about another major change to the kernel - so after a while you have several such major features added, it's unreasonable to add a major number every time.

      So while I agree with your general ideas, it's certainly not that easy in the "release early, release fast" world of open source software, as with the fairly rapid addition of ma

    • by AmiMoJo ( 196126 ) *

      The Linux kernel V3.20 is very different to 3.0, but it was such a gradual change that there was no big bump where a major number would have been incremented.

      For projects that evolve that way it can be helpful to keep version numbers fairly small. It's easier to talk about the 3.x era than the 3.0-3.17 era.

      • by fnj ( 64210 )

        I like it. You zeroed in on the only possible justification that could possibly hold any water at all. I don't buy it, but it's not crazy reasoning.

    • by symes ( 835608 )

      If you assume the regular versioning systems work with the linux kernal, then no, it is not major bump time. This whole thing is a storm in tea cup - if Linus can count much above 20 then why not bump to 4? Although I agree the bump should mark some event.

      • by fnj ( 64210 )

        If linus has trouble counting above 20, the project is in trouble. If you go with 4.0, what happens when it hits 20.0? You are just putting off the inevitable reckoning. He should, with respect, LEARN TO COUNT.

    • As matter of fact bug-fixes that don't break backwards compatibilities usually have their own separate number (the last number in the number version):

      MAJOR_VERSION . MINOR_VERSION . BUG_FIXES

      So you can update your software safely if you keep the same major and minor versions.

      In my project the upper echelon of the company wanted to stress out that this was version two of our product (even though the "second version" does not share any code at all with the first) so we ended up introducing one more number to

      • by fnj ( 64210 )

        Danger, this organization does not have a level of institutional intelligence sufficient for you to consider a continuance of your working relationship.

        • It was not so much a case of micro-management and more a case of "either way is fine by me", if I had insisted on keeping 3 numbers they would let me. We only realized the problems of saying 4 numbers out loud after a while when it was too late to change it.

  • OS L (Score:5, Funny)

    by io333 ( 574963 ) on Friday February 13, 2015 @10:20AM (#49046625)

    Just call it OS L and be done with it.

    "No it's not OS el you incompetent hag, it's OS fifty!"

  • by Anonymous Coward

    It makes me sad. Not about version numbering. Why does Linus force the users to use Google+. It somehow feels very wrong to me.

    • It's not like any blog hosting/software would be different. One still have to register to leave a comment - as it always was.

    • by Rich0 ( 548339 )

      It makes me sad. Not about version numbering. Why does Linus force the users to use Google+. It somehow feels very wrong to me.

      It is a silly poll to express a completely non-binding opinion. Linus will do whatever he feels like doing in the end.

      It isn't like the kernel now has a GOOGLE_ID config item that is validated before it will compile/run.

    • by msobkow ( 48369 )

      On the flip side, I actually *see* Linus' posts on Google+, whereas on Crackbook they'd be buried under the deluge of cat videos... :P

  • Join the crowd (Score:4, Insightful)

    by swimboy ( 30943 ) on Friday February 13, 2015 @10:36AM (#49046763)

    Why not adopt the new standard, jump your major revision number to 10, and then leave it there forever; just like Apple and Microsoft?

  • by jones_supa ( 887896 ) on Friday February 13, 2015 @10:59AM (#49046937)

    It is artificial to bump the major version every time when the minor version merely begins to "feel too large".

    The development of Linux is mostly incremental. A date code or just a single rolling number might suit the project better.

  • imposter! (Score:5, Funny)

    by Anonymous Coward on Friday February 13, 2015 @11:22AM (#49047109)
    Asking for people to vote on things?! Linus' email has obviously been haxxed.
  • The main thing I'd like to see for 4.0 is a massive simplification of the kernel, removing features that are no longer used anywhere. There's a lot of duplicated functionality in the kernel - two different ways to report hotplug events, three different ways to report ACPI events, several dozen filesystems, some of which don't actually work or even have userland tools that will compile on modern kernels.

    So I'd like to see a winnowing of kernel features, down to a saner, all-known-to-work set.

    Also, can we ple

  • by nbritton ( 823086 ) on Friday February 13, 2015 @12:13PM (#49047565)

    Follow the Ubuntu versioning scheme, it's simple... kernel was release in Febuary 2015, then you would call it 15.2

    • I like this suggestion. There could be revisions by year, month and day. So 15.2.13 would be Feb. 13, 2015. There would be a need for a few times with multiple releases in a day. This could be done with an optional sequence number: 15.2.13-3 for the third release for 2/13/15 (or 15/2/13 for a more rational date format). At least the version numbering has some meaning. It's almost meaningless to me to see 3.16.0-30 as a version number.
  • Will he just start over again, with a new kernel?

    Save the major version bumps for large refactorings.

  • Get with the trend guys.

    Or just LinuX.

  • Is Pluto a major or minor planet?
  • Linus missed the knuth converge to pi opportunity.

    Failing that, a 6 digit hex string is how nature intended it. One can then plot users graphically by version number.

    If you ever run past 256 major versions, there's always the alpha channel. :)

  • People keep shouting here that google plus is dead, and that I'm the only person left on the entire planet who isn't on facebook. Why are we linking to google plus on the front page then? Is Torvalds on the google payroll now or something?
    • by myrdos2 ( 989497 )
      Because there's a Linux poll there about kernel numbers. Do try to keep up with the conversation.
  • Obviously, the next verision of Linux needs to be "Linux 11 for Computers" - we need to look more advanced than OS X and Windows 10.

    Other variants can be "Linux 2015 Mobile Edition" for phones and tablets, and "Linux Server 2011 (Based on Linux 3.0 technology)" for servers.

  • I would change major when features change, and minor for bug fixes only.

    That way you can quickly tell if your kernel has the exact same features than another one, and if you have got the same bug fixes.

    Then yes, it would be a good moment to start with 4.0

  • ... so I can stay away from it and know when to change to BSD

Everybody likes a kidder, but nobody lends him money. -- Arthur Miller

Working...