Announcement

Collapse
No announcement yet.

Linus Talks Of Linux 2.8 Or Linux 3.0; Ending Linux 2.6

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • NomadDemon
    replied
    3.x for wayland stable and default!

    Leave a comment:


  • ChuckDriver
    replied
    Odd for Development

    Originally posted by schmidtbag View Post
    i don't understand exactly why they skip over odd numbers (2.7 and 2.9)
    Historically, the odd minor revision numbers were the unstable releases where new features would be introduced. ALSA, for example, was introduced in the 2.5 series, then became part of the stable 2.6 kernel. Now that new features are regularly introduced to the kernel, this may change.

    Leave a comment:


  • Nevertime
    replied
    I like the idea of using the year and month of release for the numbering system.

    Leave a comment:


  • DeepDayze
    replied
    Originally posted by RealNC View Post
    The current version number scheme is wrong anyway. With the model now used by the kernel, it makes more sense to release the next version as 2.7.0 and drop the fourth number completely. What use does it have anyway? After 2.7.0 is released, merge window for 2.8.0 opens, and updates to the current stable kernel should be tagged as 2.7.1, 2.7.2, etc.

    Edit:
    Also, they shouldn't be afraid to increase the major number. For example, removing the BKL was big enough of a change to go to 3.0.0.

    Yes something as major as removing the BKL code or major infrastructure/ABI changes should warrant a major version bump. It should have been considered before, as even the 2.4 series has like 37 revisions already.

    Leave a comment:


  • schmidtbag
    replied
    i don't understand exactly why they skip over odd numbers (2.7 and 2.9) and imo, if they were going to move to 2.8.0 or 3.0.0, they should have done that when ditching HAL for udev. to me, that was a pretty big change for the kernel. i feel like new version numbers are just thrown out arbitrarily and i really don't like it - except for the very last digit, there doesn't appear to be any particular meaning to any of the numbers.

    i agree with the guy who wants to do version numbers by date. considering linux has been stable for about a full decade, we're just going to either go up in little increments like 2.6.37, .38, .39, .40, and so on, or, we're going to go up from 2.6.40 to 3.0.0 without any particular reason.

    i feel like 2.7 should be the next number, and 2.7 should not be breached until all KERNEL related current issues (such as the power regression) are fixed. but like stated before, we should have been in 2.7 a long time ago when HAL was replaced.

    Leave a comment:


  • sirdilznik
    replied
    In a numbering system sense it wouldn't be the best idea, but I think it would be hilarious if he changed the next kernel version to 2.7 as a way of poking fun at SCO's ridiculous argument years ago that code for the Linux 2.7 kernel was stolen from them.

    Leave a comment:


  • Eduard Munteanu
    replied
    Actually, Linus' latest idea of going 3.x with x being the minor isn't bad at all, as long as we don't go 4.x after 3.40

    Leave a comment:


  • Eduard Munteanu
    replied
    My take on this is version numbers should attempt to be informative or at least avoid being misleading. So they can be based on some milestone, like Wine 1.x, or reflect major architectural changes.

    Now I'm not sure any of that holds for Linux, and there doesn't seem to be any significant mid/long-term roadmap. This is okay and maybe natural for such a project, as opposed to, say, Wine, as it's difficult to objectively score achievements (see server vs desktop users). Well, the BKL removal is one important change, but it's not like it happened overnight or like it's something a user can directly experience and benefit from.

    And numbers aren't really getting big: it's going to be a long time before we see even 2.6.100.

    The development model is suited to incremental but significant changes, and this isn't going to change any time soon. It's tempting to say "hey, let's take this opportunity to make some major changes or go into a freeze or both", but that probably isn't better.

    So unless there's a half-good reason to do that, I'm not sure this change is warranted. And it's probably better if Linux doesn't get a marketing department.

    Leave a comment:


  • devius
    replied
    About time. I was beggining to think that the 2.6 kernel would go into the hundreds...

    Leave a comment:


  • V!NCENT
    replied
    He should scrap the 2.6.40 to 6.40. The first number is useless now that it everybody knows that the first stable release of Linux, ever, has been delivered a very, very, very long time ago. Uneven like 2.6.39 indicates unstable and 2.6.40.indicates stable. The first number is absolutely useless nowadays.

    Now the second number 2.6.40 indicates an acrhitecture overhaul. So either keep 6 or dare to make a 2.7.0 kernel change towards a stable 2.8.0. I don't think that it would be a problem if the code stays the same but with slow modularization over time. 2.7.1 indicating unstable and 2.7.2 indicating the first stable release. Having 2.8.0, or rather 8.0, as a modular kernel.

    The kernel is getting fat. I think taking modular design beyond kernel modules is great. I don't think that breaking stuff is good. I'd say pull a Gnome 3.x at the incremental change planning of Gnome 2.x.

    Anything else in terms of versioning numbers is total horror and only useful as Wine now has a 'useful' 1.x version scheme while I wished they still 0.9.x'd the sucker.

    Leave a comment:

Working...
X